RE: [PATCH 0/2] bpf, net: Allow setting SO_TIMESTAMPING* from BPF

[John Fastabend <john.fastabend@gmail.com>]

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?

Otherwise the series lgtm.

> 
> 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
> 
>