Re: [PATCH net] net: fall back to skb_iif for the timestamping pktinfo if_index

[JR Lanteigne <root@dnim.dev>]

Willem de Bruijn wrote:
> I don't mind adding a fallback. As long as possibly passing an
> aggregate (or tunnel) device cannot cause regressions to existing
> users, notably chrony and linuxptp.

I checked both.

linuxptp does not use SCM_TIMESTAMPING_PKTINFO at all, and its event
sockets are opened per port and bound with SO_BINDTODEVICE, so
timestamps are attributed to an interface by socket, not by this
cmsg.

chrony matches the cmsg if_index only against interfaces listed in
its hwtimestamp directive, with the PHC resolved by its own
ETHTOOL_GET_TS_INFO on the configured name. An index it was not
configured for (an unconfigured aggregate) fails the lookup exactly
like the 0 it gets today, where it silently degrades to the kernel
software timestamp. If the user did configure the aggregate, the
value is nothing new either: on kernels without this cmsg (pre-4.13)
chrony already falls back to the IP_PKTINFO/IPV6_PKTINFO index,
which is the same aggregate device skb_iif holds, since
__netif_receive_skb_core() resets skb_iif after the bond/bridge
rx_handler rewrites skb->dev and inet_iif()/IP6CB(skb)->iif report
that device.

The fallback also only fires when the napi lookup already failed, so
the bonding configurations the referenced commit was added for,
where the napi id resolves to the physical slave, are unchanged.