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

[Michal Swiatkowski]

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
> 
> 
>