From: Willem de Bruijn <willemdebruijn.kernel@gmail•com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix•de>,
Willem de Bruijn <willemdebruijn.kernel@gmail•com>
Cc: netdev@vger•kernel.org, "(JC),
Jayachandran" <j-rameshbabu@ti•com>,
"David S. Miller" <davem@davemloft•net>,
Andrew Lunn <andrew+netdev@lunn•ch>,
Chintan Vankar <c-vankar@ti•com>,
Danish Anwar <danishanwar@ti•com>, Daolin Qiu <d-qiu@ti•com>,
Eric Dumazet <edumazet@google•com>,
Felix Maurer <fmaurer@redhat•com>,
Jakub Kicinski <kuba@kernel•org>,
Paolo Abeni <pabeni@redhat•com>,
Richard Cochran <richardcochran@gmail•com>,
Simon Horman <horms@kernel•org>
Subject: Re: [PATCH RFC net-next v2 2/2] af_packet: Add port specific handling for HSR
Date: Mon, 16 Mar 2026 16:12:41 -0400 [thread overview]
Message-ID: <willemdebruijn.kernel.1fbf050c50d62@gmail.com> (raw)
In-Reply-To: <20260313160410.LEhav8Xz@linutronix.de>
Sebastian Andrzej Siewior wrote:
> On 2026-03-13 10:22:28 [+0100], To Willem de Bruijn wrote:
> > On 2026-03-12 17:43:36 [-0400], Willem de Bruijn wrote:
> > > > Yes, this is RX. If I open packet socket, bind to hsr0, how do I filter
> > > > for packets from one of the slaves?
> > >
> > > I was thinking of attaching directly to the slave devices.
> >
> > That could work. Let me see.
>
> Halfway done. What we went down to is:
>
> Send with header -> eth0/ eth1 + SO_MARK for header + port 1/ 2
> Send without header -> hsr0 + SO_MARK 1/2 port 1/ 2
> RX -> listen on eth0/ eth1
>
> Now this compiles and I look into userland and am currently stuck with
> the problem that it does not expect "two devices". It is not impossible
> but…
>
> > > > After some thinking and browsing through the packet code:
> > > > The hsr stack creates hsrX. If it would create additionally hsrX_A and
> > > > hsrX_B in order to be able to send and receive only on the relevant
> > > > slave device then I wouldn't need the filters in packet code. That could
> > > > work…
> > >
> > > That's another option.
> >
> > Okay. Let me add this as plan B then.
>
> At this point I am considering this which would avoid having to use
> hsr0+eth1 for one direction depending on whether I have to send with or
> without the header. But this might lead to other problems such as ip
> address and so on.
>
> The suggested changes to af_packet, that remains a hard no?
Yes. Packet sockets are largely superseded by XDP and AF_XDP when it
comes to new functionality. And were never open for such protocol
specific logic.
Protocol independent extensions, such as reading skb->mark as part of
extended auxdata, could be up for debate. But again, we already have
XDP and AF_XDP which allow passing arbitrary metadata to/from
userspace. That is preferable over adding new structs to the ABI.
If you only want to attach to a single (hsr0) device, I still think
passing the data inline might work. Either by overriding existing
fields such as a MAC addr (a hack for sure) or something in the HSR
header (it as the direction? or by inserting a custom header (or
trailer) akin to virtio_net_hdr for tun/tap. But custom to your
workload.
next prev parent reply other threads:[~2026-03-16 20:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-09 15:52 [PATCH RFC net-next v2 0/2] hsr: Add additional info to send/ receive skbs Sebastian Andrzej Siewior
2026-03-09 15:52 ` [PATCH RFC net-next v2 1/2] hsr: Allow to send a specific port and with HSR header Sebastian Andrzej Siewior
2026-03-09 15:52 ` [PATCH RFC net-next v2 2/2] af_packet: Add port specific handling for HSR Sebastian Andrzej Siewior
2026-03-10 1:38 ` Willem de Bruijn
2026-03-10 10:55 ` Sebastian Andrzej Siewior
2026-03-10 21:35 ` Willem de Bruijn
2026-03-12 15:42 ` Sebastian Andrzej Siewior
2026-03-12 21:43 ` Willem de Bruijn
2026-03-13 9:22 ` Sebastian Andrzej Siewior
2026-03-13 16:04 ` Sebastian Andrzej Siewior
2026-03-16 20:12 ` Willem de Bruijn [this message]
2026-03-17 17:29 ` Sebastian Andrzej Siewior
2026-03-19 13:29 ` Willem de Bruijn
2026-03-19 14:26 ` Sebastian Andrzej Siewior
2026-03-19 16:27 ` Willem de Bruijn
2026-03-24 16:38 ` Sebastian Andrzej Siewior
2026-04-02 16:32 ` Sebastian Andrzej Siewior
2026-04-06 14:47 ` Willem de Bruijn
2026-04-16 16:18 ` Sebastian Andrzej Siewior
2026-04-21 7:41 ` Willem de Bruijn
2026-04-22 13:27 ` Sebastian Andrzej Siewior
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=willemdebruijn.kernel.1fbf050c50d62@gmail.com \
--to=willemdebruijn.kernel@gmail$(echo .)com \
--cc=andrew+netdev@lunn$(echo .)ch \
--cc=bigeasy@linutronix$(echo .)de \
--cc=c-vankar@ti$(echo .)com \
--cc=d-qiu@ti$(echo .)com \
--cc=danishanwar@ti$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=edumazet@google$(echo .)com \
--cc=fmaurer@redhat$(echo .)com \
--cc=horms@kernel$(echo .)org \
--cc=j-rameshbabu@ti$(echo .)com \
--cc=kuba@kernel$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
--cc=richardcochran@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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