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