Received-SPF: pass (google.com: domain of linux-kernel+bounces-29177-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Wed, 17 Jan 2024 10:55:01 -0500
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Martin KaFai Lau <martin.lau@linux.dev>, 
 =?UTF-8?B?SsO2cm4tVGhvcmJlbiBIaW56?= <j-t.hinz@alumni.tu-berlin.de>
Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>, 
 Alexei Starovoitov <ast@kernel.org>, 
 Daniel Borkmann <daniel@iogearbox.net>, 
 Andrii Nakryiko <andrii@kernel.org>, 
 "David S. Miller" <davem@davemloft.net>, 
 Eric Dumazet <edumazet@google.com>, 
 Jakub Kicinski <kuba@kernel.org>, 
 Paolo Abeni <pabeni@redhat.com>, 
 Shuah Khan <shuah@kernel.org>, 
 Arnd Bergmann <arnd@arndb.de>, 
 Deepa Dinamani <deepa.kernel@gmail.com>, 
 bpf@vger.kernel.org, 
 linux-kernel@vger.kernel.org, 
 netdev@vger.kernel.org, 
 linux-kselftest@vger.kernel.org
Message-ID: <65a7f855821cc_6d500294d0@willemb.c.googlers.com.notmuch>
In-Reply-To: <51fd5249-140a-4f1b-b20e-703f159e88a3@linux.dev>
References: <20240115134110.11624-1-j-t.hinz@alumni.tu-berlin.de>
 <65a69e1be51ef_380df0294d9@willemb.c.googlers.com.notmuch>
 <51fd5249-140a-4f1b-b20e-703f159e88a3@linux.dev>
Subject: Re: [PATCH bpf-next] bpf: Allow setting SO_TIMESTAMPING* with
 bpf_setsockopt()
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

Martin KaFai Lau wrote:
> On 1/16/24 7:17 AM, Willem de Bruijn wrote:
> > J=C3=B6rn-Thorben Hinz wrote:
> >> A BPF application, e.g., a TCP congestion control, might benefit fro=
m or
> >> even require precise (=3Dhardware) packet timestamps. These timestam=
ps are
> >> already available through __sk_buff.hwtstamp and
> >> bpf_sock_ops.skb_hwtstamp, but could not be requested: BPF programs =
were
> >> not allowed to set SO_TIMESTAMPING* on sockets.
> =

> This patch only uses the SOF_TIMESTAMPING_RX_HARDWARE in the selftest. =
How about =

> others? e.g. the SOF_TIMESTAMPING_TX_* that will affect the sk->sk_erro=
r_queue =

> which seems not good. If rx tstamp is useful, tx tstamp should be usefu=
l also?

Good point. Or should not be allowed to be set from BPF.

That significantly changes process behavior, e.g., by returning POLLERR.
 =

> >>
> >> Enable BPF programs to actively request the generation of timestamps=

> >> from a stream socket. The also required ioctl(SIOCSHWTSTAMP) on the
> >> network device must still be done separately, in user space.
> =

> hmm... so both ioctl(SIOCSHWTSTAMP) of the netdevice and the =

> SOF_TIMESTAMPING_RX_HARDWARE of the sk must be done?
> =

> I likely miss something. When skb is created in the driver rx path, the=
 sk is =

> not known yet though. How the SOF_TIMESTAMPING_RX_HARDWARE of the sk af=
fects the =

> skb_shinfo(skb)->hwtstamps?

Indeed it does not seem to do anything in the datapath.

Requesting SOF_TIMESTAMPING_RX_SOFTWARE will call net_enable_timestamp
to start timestamping packets.

But SOF_TIMESTAMPING_RX_HARDWARE does not so thing.

Drivers do use it in ethtool get_ts_info to signal hardware
capabilities. But those must be configured using the ioctl.

It is there more for consistency with the other timestamp recording
options, I suppose.