Re: [net-next v2 2/2] tcp: Add receive timestamp support for receive zerocopy.

[Arjun Roy <arjunroy@google.com>]

On Thu, Feb 4, 2021 at 4:00 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Thu, 4 Feb 2021 15:03:40 -0800 Arjun Roy wrote:
> > But, if it's an IN or IN-OUT field, it seems like mandating that the
> > application set it to 0 could break the case where a future
> > application sets it to some non-zero value and runs on an older
> > kernel.
>
> That usually works fine in practice, 0 means "do what old kernels did /
> feature not requested", then if newer userspace sets the field to non-0
> that means it requires a feature the kernel doesn't support. So -EINVAL
> / -EOPNOTSUPP is right. BPF syscall has been successfully doing this
> since day 1, I'm not aware of any major snags.
>

Alright, sounds good.

> > And allowing it to be non-zero can maybe yield an unexpected
> > outcome if an old application that did not zero it runs on a newer
> > kernel.
>
> Could you refresh our memory as to why we can't require the application
> to pass zero-ed memory to TCP ZC? In practice is there are max
> reasonable length of the argument that such legacy application may pass
> so that we can start checking at a certain offset?
>

Actually I think that's fine. We have hitherto been just using length
checks to distinguish between feature capability for rx. zerocopy but
I think we can draw the line at this point (now that there's
ambiguity) and start requiring zero'd memory.

I will send out a patch soon; reserved u32 field, must be set to 0 for
the current kernel, can be non-zero and in/out in future kernels as
discussed.

Thanks,
-Arjun


> > So: maybe the right move is to mark it as reserved, not care what the
> > input value is, always set it to 0 before returning to the user, and
> > explicitly mandate that any future use of the field must be as an
> > OUT-only parameter?
>