Re: [PATCH v2 bpf-next/net 1/5] ethtool: Introduce ETHTOOL_MSG_TSINFO_SET for virtual interfaces.

[Stanislav Fomichev <sdf.kernel@gmail.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?