From: Jakub Kicinski <kuba@kernel.org>
To: Arjun Roy <arjunroy@google.com>
Cc: Leon Romanovsky <leon@kernel.org>,
David Ahern <dsahern@gmail.com>,
Arjun Roy <arjunroy.kdev@gmail.com>,
David Miller <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>,
Eric Dumazet <edumazet@google.com>,
Soheil Hassas Yeganeh <soheil@google.com>
Subject: Re: [net-next v2 2/2] tcp: Add receive timestamp support for receive zerocopy.
Date: Thu, 4 Feb 2021 16:00:06 -0800 [thread overview]
Message-ID: <20210204160006.439ce566@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <CAOFY-A0_MU3LP2HNY_5a1XZLZHDr3_9tDq6v-YB-FSJJb7508g@mail.gmail.com>
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.
> 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?
> 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?
next prev parent reply other threads:[~2021-02-05 0:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-21 0:41 [net-next v2 0/2] tcp: add CMSG+rx timestamps to rx. zerocopy Arjun Roy
2021-01-21 0:41 ` [net-next v2 1/2] tcp: Remove CMSG magic numbers for tcp_recvmsg() Arjun Roy
2021-01-21 0:41 ` [net-next v2 2/2] tcp: Add receive timestamp support for receive zerocopy Arjun Roy
2021-01-23 4:07 ` Jakub Kicinski
2021-01-23 5:55 ` David Ahern
2021-01-25 6:15 ` Leon Romanovsky
2021-02-02 2:06 ` David Ahern
2021-02-02 2:20 ` Arjun Roy
2021-02-02 6:52 ` Leon Romanovsky
2021-02-04 23:03 ` Arjun Roy
2021-02-05 0:00 ` Jakub Kicinski [this message]
2021-02-05 1:32 ` Arjun Roy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210204160006.439ce566@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com \
--to=kuba@kernel.org \
--cc=arjunroy.kdev@gmail.com \
--cc=arjunroy@google.com \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=edumazet@google.com \
--cc=leon@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=soheil@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.