From: Stanislav Fomichev <sdf.kernel@gmail.com>
To: Kuniyuki Iwashima <kuniyu@google.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <martin.lau@linux.dev>,
Stanislav Fomichev <sdf@fomichev.me>,
Andrii Nakryiko <andrii@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
Jiri Olsa <jolsa@kernel.org>, Andrew Lunn <andrew@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
Willem de Bruijn <willemb@google.com>,
Kuniyuki Iwashima <kuni1840@gmail.com>,
bpf@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v2 bpf-next/net 1/5] ethtool: Introduce ETHTOOL_MSG_TSINFO_SET for virtual interfaces.
Date: Fri, 12 Jun 2026 19:29:05 -0700 [thread overview]
Message-ID: <aiy_eV7RP2nPlxmJ@devvm7509.cco0.facebook.com> (raw)
In-Reply-To: <20260613010039.1362312-2-kuniyu@google.com>
On 06/13, Kuniyuki Iwashima wrote:
> Before enabling SO_TIMESTAMPING, applications typically try to
> enable hardware timestamping on network interfaces via SIOCSHWTSTAMP
> (or ETHTOOL_MSG_TSCONFIG_SET).
>
> The timestamping capability on an interface can be checked via
> ETHTOOL_MSG_TSINFO_GET:
>
> # ethtool -T eth0
> Time stamping parameters for eth0:
> Capabilities:
> hardware-transmit
> software-transmit
> hardware-receive
> software-receive
> software-system-clock
> hardware-raw-clock
> PTP Hardware Clock: none
> Hardware Transmit Timestamp Modes:
> off
> on
> Hardware Receive Filter Modes:
> none
> all
>
> These operations rely on the driver implementing two callbacks,
> dev->netdev_ops->ndo_hwtstamp_{get,set}().
>
> However, among all virtual network interfaces, only bond and
> macvlan currently implement them.
>
> As a result, most virtual interfaces cannot advertise the
> capabilities of their underlying devices:
>
> # ip link add ipvl0 link eth0 type ipvlan mode l2 bridge
> # ethtool -T ipvl0
> Time stamping parameters for ipvl0:
> Capabilities:
> software-receive
> software-system-clock
> PTP Hardware Clock: none
> Hardware Transmit Timestamp Modes: none
> Hardware Receive Filter Modes: none
>
> While these callbacks could be implemented in each virtual
> interface, this approach is limited to those directly linked
> to a physical device.
>
> Not all virtual interfaces are tied to real hardware; for
> instance, packets from UDP tunnel devices eventually pass
> through physical devices and can be hardware-timestamped there.
>
> Let's allow configuring the hardware timestamping capability on
> virtual interfaces via ETHTOOL_MSG_TSINFO_SET.
I don't have a lot of state on this, but when adding xdp hw timestamping
I remember fighting a lot with those apis. Now we are adding another
one, but (seemingly?) for sw devices. Can you explain a bit more about
why can't existing SIOCGHWTSTAMP (or ETHTOOL_MSG_TSCONFIG_SET) fallback
to your new dev->tsinfo.enabled codepaths for the devices that
don't implement the ops?
next prev parent reply other threads:[~2026-06-13 2:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-13 0:59 [PATCH v2 bpf-next/net 0/5] bpf: Support RX/TX HW timestamp proxy Kuniyuki Iwashima
2026-06-13 0:59 ` [PATCH v2 bpf-next/net 1/5] ethtool: Introduce ETHTOOL_MSG_TSINFO_SET for virtual interfaces Kuniyuki Iwashima
2026-06-13 2:29 ` Stanislav Fomichev [this message]
2026-06-13 3:43 ` Kuniyuki Iwashima
2026-06-13 0:59 ` [PATCH v2 bpf-next/net 2/5] bpf: Rename bpf_kfunc_set_tcp_reqsk to bpf_kfunc_set_sched_cls Kuniyuki Iwashima
2026-06-13 1:00 ` [PATCH v2 bpf-next/net 3/5] bpf: Add bpf_skb_set_hwtstamp() Kuniyuki Iwashima
2026-06-13 1:00 ` [PATCH v2 bpf-next/net 4/5] bpf: Add kfunc to proxy TX HW Timestamp Kuniyuki Iwashima
2026-06-13 1:00 ` [PATCH v2 bpf-next/net 5/5] selftest: bpf: Add test for hwtstamp proxy Kuniyuki Iwashima
2026-06-13 1:31 ` Alexei Starovoitov
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=aiy_eV7RP2nPlxmJ@devvm7509.cco0.facebook.com \
--to=sdf.kernel@gmail.com \
--cc=andrew@lunn.ch \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=eddyz87@gmail.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kuba@kernel.org \
--cc=kuni1840@gmail.com \
--cc=kuniyu@google.com \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
--cc=willemb@google.com \
--cc=yonghong.song@linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox