[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bdffeca8e222b0126100dec5dcd9d9b186ea6905.camel@mailbox.tu-berlin.de>
Date: Tue, 4 Jul 2023 18:11:51 +0200
From: Jörn-Thorben Hinz <jthinz@...lbox.tu-berlin.de>
To: John Fastabend <john.fastabend@...il.com>, <bpf@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>,
<linux-kselftest@...r.kernel.org>
CC: Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
"Martin KaFai Lau" <martin.lau@...ux.dev>,
"David S. Miller" <davem@...emloft.net>,
"Eric Dumazet" <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
"Paolo Abeni" <pabeni@...hat.com>, Shuah Khan <shuah@...nel.org>,
Willem de Bruijn <willemb@...gle.com>,
Deepa Dinamani <deepa.kernel@...il.com>
Subject: Re: [PATCH 0/2] bpf, net: Allow setting SO_TIMESTAMPING* from BPF
Thank you for the feedback.
Just noticed I missed the “bpf-next” designation in the subject. Will
add that in v2.
On Mon, 2023-07-03 at 14:25 -0700, John Fastabend wrote:
> Jörn-Thorben Hinz wrote:
> > BPF applications, e.g., a TCP congestion control, might benefit
> > from
> > precise packet timestamps. These timestamps are already available
> > in
> > __sk_buff and bpf_sock_ops, but could not be requested: A BPF
> > program
> > was not allowed to set SO_TIMESTAMPING* on a socket. This change
> > enables
> > BPF programs to actively request the generation of timestamps from
> > a
> > stream socket.
> >
> > To reuse the setget_sockopt BPF prog test for
> > bpf_{get,set}sockopt(SO_TIMESTAMPING_NEW), also implement the
> > missing
> > getsockopt(SO_TIMESTAMPING_NEW) in the network stack.
> >
> > I reckon the way I added getsockopt(SO_TIMESTAMPING_NEW) causes an
> > API
> > change: For existing users that set SO_TIMESTAMPING_NEW but queried
> > SO_TIMESTAMPING_OLD afterwards, it would now look as if no
> > timestamping
> > flags have been set. Is this an acceptable change? If not, I’m
> > happy to
> > change getsockopt() to only be strict about the newly-implemented
> > getsockopt(SO_TIMESTAMPING_NEW), or not distinguish between
> > SO_TIMESTAMPING_NEW and SO_TIMESTAMPING_OLD at all.
>
> Yeah, I think it would be best if we keep the old behavior and let
> SO_TIMESTAMPING_OLD return timestamps for both new/old. It looks
> like it should be relatively easy to implement?
Alright, I guessed that would be preferred.
Yes, if there is no objection to making the added
getsockopt(SO_TIMESTAMPING_NEW) this tiny bit more “strict”, it’s just
a matter of modifying the if inserted in sk_getsockopt(). (And, well,
in the other case I would even remove this if.)
>
> Otherwise the series lgtm.
Great, thanks.
>
> >
> > Jörn-Thorben Hinz (2):
> > net: Implement missing getsockopt(SO_TIMESTAMPING_NEW)
> > bpf: Allow setting SO_TIMESTAMPING* with bpf_setsockopt()
> >
> > include/uapi/linux/bpf.h | 3 ++-
> > net/core/filter.c | 2 ++
> > net/core/sock.c | 9 +++++++--
> > tools/include/uapi/linux/bpf.h | 3 ++-
> > tools/testing/selftests/bpf/progs/bpf_tracing_net.h | 2 ++
> > tools/testing/selftests/bpf/progs/setget_sockopt.c | 4 ++++
> > 6 files changed, 19 insertions(+), 4 deletions(-)
> >
> > --
> > 2.39.2
> >
Powered by blists - more mailing lists