On Mon, Jul 12, 2021 at 02:28:42PM +0200, Tobias Waldekranz wrote: > > After cutting my teeth myself with Tobias' patches, I tend to agree with > > the idea that the macvlan offload framework is not a great fit for the > > software bridge data plane TX offloading. Some reasons: > > I agree. I was trying to find an API that would not require adding new > .ndos or other infrastructure. You can see in my original RFC cover that > this was something I wrestled with. > > > - the sb_dev pointer is necessary for macvlan because you can have > > multiple macvlan uppers and you need to know which one this packet > > came from. Whereas in the case of a bridge, any given switchdev net > > device can have a single bridge upper. So a single bit per skb, > > possibly even skb->offload_fwd_mark, could be used to encode this bit > > of information: please look up your FDB for this packet and > > forward/replicate it accordingly. > > In fact, in the version I was about to publish, I reused > skb->offload_fwd_mark to encode precisely this property. It works really > well. Maybe I should just publish it, even with the issues regarding > mv88e6xxx. Let me know if you want to take a look at it. I am on it already, I have a 25-patch series that is currently undergoing testing (yes, it changes all switchdev drivers to call switchdev_bridge_port_offload() and switchdev_bridge_port_unoffload(), and it also moves the switchdev object replay helpers to push mode, and only then it hooks a "bool tx_fwd_offload" argument to the switchdev_bridge_port_offload() call). If all goes well and I still have some time today I will publish it for review. Naturally the final submissions, when net-next reopens, will be in much smaller chunks.
