From: JR Lanteigne <root@dnim.dev>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Eric Dumazet <edumazet@google.com>,
Kuniyuki Iwashima <kuniyu@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Willem de Bruijn <willemb@google.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org, Simon Horman <horms@kernel.org>,
Miroslav Lichvar <mlichvar@redhat.com>,
richardcochran@gmail.com
Subject: Re: [PATCH net] net: fall back to skb_iif for the timestamping pktinfo if_index
Date: Mon, 24 Aug 2026 13:55:53 -0300 [thread overview]
Message-ID: <178759055328.4181951.10346301845266420247@dnim.dev> (raw)
In-Reply-To: <willemdebruijn.kernel.1e07ba16c4cf4@gmail.com>
Willem de Bruijn wrote:
> It may be possible to detect whether an skb_iif points to a physical
> or aggregate device (e.g., through lower_dev)? If so, then the value
> can still be used in most cases.
That only guesses less often (tunnels register no lower adjacency).
I agree with Miroslav: 0 when the physical interface is unknown.
The userspace check fixes chrony only; every other consumer of
SCM_TIMESTAMPING_PKTINFO has to rediscover that if_index can be 0
and grow its own IP_PKTINFO fallback. The kernel is the one place a
fix reaches all of them.
The gap on cpsw: one napi serves both ports, the driver delivers
with netif_receive_skb() so the id is never set, and it would name
port 1 for every frame if it were. The driver knows the source port
per packet (CPDMA_RX_SOURCE_PORT) and needs a way to hand it to
put_ts_pktinfo(), e.g. via skb_shared_hwtstamps.
next prev parent reply other threads:[~2026-08-24 16:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-23 5:21 [PATCH net] net: fall back to skb_iif for the timestamping pktinfo if_index JR Lanteigne
2026-08-24 2:21 ` Willem de Bruijn
2026-08-24 10:24 ` JR Lanteigne
2026-08-24 7:58 ` Miroslav Lichvar
2026-08-24 10:24 ` JR Lanteigne
2026-08-24 14:06 ` Willem de Bruijn
2026-08-24 16:55 ` JR Lanteigne [this message]
2026-08-24 18:35 ` Willem de Bruijn
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=178759055328.4181951.10346301845266420247@dnim.dev \
--to=root@dnim.dev \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=mlichvar@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.com \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.