linux-kernel - Re: [RFC net-next v1 2/2] net: dsa: add option for bridge port HW offload

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z4+w1O/tS7nw0jlS@mev-dev.igk.intel.com>
Date: Tue, 21 Jan 2025 15:36:04 +0100
From: Michal Swiatkowski <michal.swiatkowski@...ux.intel.com>
To: Aryan Srivastava <Aryan.Srivastava@...iedtelesis.co.nz>
Cc: "andrew@...n.ch" <andrew@...n.ch>,
	"olteanv@...il.com" <olteanv@...il.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"jiri@...nulli.us" <jiri@...nulli.us>,
	"horms@...nel.org" <horms@...nel.org>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>
Subject: Re: [RFC net-next v1 2/2] net: dsa: add option for bridge port HW
 offload

On Mon, Jan 20, 2025 at 09:36:57PM +0000, Aryan Srivastava wrote:
> On Mon, 2025-01-20 at 04:12 +0100, Andrew Lunn wrote:
> > > > 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?
> Yes, so we use various in-kernel (eBPF) and some out of tree methods
> (netmap). To service both, I thought that a devlink config would be
> best.
> 
> Also aside from specific kernel feature use-cases the actual port we
> are trying to service is meant to be a dedicated NIC, whose
> implementation detail is that it is on a switch chip. By offloading
> aspects of its config, we end up with inconsistent behaviour across NIC
> ports on our devices. As the port is not meant to behave like a
> switchport, the fact it happens to be on the end of a switch should not
> force it to HW offload bridging. The HW bridging results in CPU bypass,
> where as SW bridging will be a more desirable method of bridging for
> this port. Therefore it is desirable to have a method to configure
> certain ports for SW bridging only, rather than the driver
> automatically choosing to do HW offload if capable.
> > 
> > > > 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.
> > 
> Ah yes, I understand. I will add the request in the cover letter next
> time, but essentially I just wanted comments about the best way to go
> about this. Specifically if there was already a method in kernel to
> prevent HW offload of certain features or if there are alternative
> methods to devlink to add specific switch config options on a per port
> basis.

For debug purpouse I am turning off HW bridge offload by setting aging to 0.
Don't know if it is appropriate in your case.

Thanks
Michal

> 
> 	Aryan
> 
> 
>