Yes, but I am having a hard time understanding how it integrates into the DSA. For example, let's take mediatek,mt7988-eth defined in /drivers/net/ethernet/mediatek /mtk_eth_soc.c and let's say a sja1105s defined in drivers/net/dsa/sja1105/sja1105_main.c is connected to it. It looks like the sja1105s::cls_flower_add() will only be called as a callback when a TC_SETUP_BLOCK is registered with the DSA subsystem. When a TC_SETUP_FT arrives it will be dispatched to mt7988-eth::ndo_setup_tc() but that driver will handle it for itself, i.e. it will setup a callback that offloads incoming flows by registering those flows in its memory. But that is not how I expect the DSA to work. The whole point is to let the switch do the offload itself, no?. Additionally, most eth drivers don't even have an internal mechanism for HW offload so when a TC_SETUP_FT comes to the DSA subsystem it will most likely be a no-op even if the switch implements the cls_flower_*() functions. Thank you in advance. On Wed, 20 Nov 2024 at 00:39, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > Hi, > > On Sat, Nov 16, 2024 at 11:11:22PM +0200, Jim Morrison wrote: > > In net/dsa/user.c in the function dsa_user_setup_tc() when TC_SETUP_FT > > command arrives, dsa_user_setup_ft_block() will be called which calls > > ndo_setup_tc() for the conduit device. > > > > What is the rationale behind this design? Why isn't the corresponding > > dsa_switch_ops::port_setup_tc() called? > > > > More specifically, what is the conduit driver expected to do when it > > receives the TC_SETUP_FT from the DSA subsystem? > > > > It seems to me that the conduit's driver can't do much as it doesn't > > even know for which switch port this ndo_setup_tc() was called. > > Did you have a look at the existing client code that is using this > infrastructure from Netfilter?
