Re: [PATCH RFC net-next v2 2/2] af_packet: Add port specific handling for HSR

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

Sebastian Andrzej Siewior wrote:
> Hi Willem,
> 
> On 2026-03-24 17:38:21 [+0100], To Willem de Bruijn wrote:
> > On 2026-03-19 12:27:57 [-0400], Willem de Bruijn wrote:
> > > 
> > > Right, so this is simple without hardware offload. Does this HW
> > > offload exist, or is this aspirational. At least for infrequent PTP
> > > it does not sound important.
> > 
> > The snippet below was for the icssg driver as-is and it works with
> > updated firmware to ignore PTP packets while HW offloading is enabled.
> …
> > With the skb_ext I had, the mechanism was mostly the same but it relied
> > only on the skb_ext data. Now it has to look at skb->mark.
> 
> Had you so time think about it? The proposed skb->mark solution kind of
> works but feels hacky.
> The version with skb_ext does touch packet's code but it is self
> contained and does not slowdown the !HSR+PTP case since the compare
> conditions are NOPed.
> How do we move forward here?

So the requirement is for a communication path between userspace and
the driver over packet sockets.

Existing options that work for both rx and tx are

- in-band: a packet header or footer
- mark, metadata
- maybe: vlan tags

These require changes in the HSR driver to use them, but no changes in
the protocol independent core logic, which includes packet sockets.

As I mentioned before we cannot sprinkle protocol specific code
throughout protocol independent core code. That quickly leads to an
unmaintainable mess. PTP over HSR is a particular small niche case,
nowhere near first in line to get an exception to this guideline.

One perhaps interesting Rx only option I had missed before is
SOF_TIMESTAMPING_OPT_PKTINFO. Would that give you the original
device ifindex today?

If so, we now only have to consider the Tx path to the HSR driver
(the Tx path directly to the other drivers do not need this metadata).

I'm not convinced that it is hard to come up with a way to send
a packet to the HSR driver with an optional header or footer or
vlan data (or skb->protocol perhaps?) that cannot be
differentiated from other traffic arriving at that ndo_start_xmit.

If all this fails, we can look into a protocol independent approach
to passing other metadata in packet sockets. to/from skb_ext or cb[],
say.

But at this point I see enough options that do not require changes
to packet sockets.

To get back to the simplest approach: skb->mark. Is there any
concrete risk that on this path that would conflict with other
uses of that field? If packet sockets inject directly into this
driver (possibly even with PACKET_QDISC_BYPASS)?