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

[Aryan Srivastava]

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