netdev - 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: <f8e90a949d08d3aba01a77f761efa41b44924345.camel@alliedtelesis.co.nz>
Date: Mon, 20 Jan 2025 21:36:57 +0000
From: Aryan Srivastava <Aryan.Srivastava@...iedtelesis.co.nz>
To: "andrew@...n.ch" <andrew@...n.ch>
CC: "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, 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.

	Aryan