[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <17952bc5-31eb-452c-8fec-957260e9afd1@lunn.ch>
Date: Mon, 20 Jan 2025 04:12:22 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Aryan Srivastava <Aryan.Srivastava@...iedtelesis.co.nz>
Cc: "olteanv@...il.com" <olteanv@...il.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"kuba@...nel.org" <kuba@...nel.org>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"jiri@...nulli.us" <jiri@...nulli.us>,
"horms@...nel.org" <horms@...nel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFC net-next v1 2/2] net: dsa: add option for bridge port HW
offload
> > This is not a very convincing description. What is your real use case
> > for not offloading?
> >
> The real use case for us is packet inspection. Due to the bridge ports
> being offloaded in hardware, we can no longer inspect the traffic on
> them, as the packets never hit the CPU.
So are you using libpcap to bring them into user space? Or are you
using eBPF?
What i'm thinking about is, should this actually be a devlink option,
or should it happen on its own because you have attached something
which cannot be offloaded to the hardware, so hardware offload should
be disabled by the kernel?
> > net-next is closed for the merge window.
> I was unsure about uploading this right now (as you said net-next is
> closed), but the netdev docs page states that RFC patches are welcome
> anytime, please let me know if this is not case, and if so I apologize
> for my erroneous submission.
It would be good to say what you are requesting comments about.
Andrew
Powered by blists - more mailing lists