On Mon, Mar 5, 2018 at 2:08 PM, Jakub Kicinski <jakub.kicin...@netronome.com> wrote: > On Mon, 5 Mar 2018 13:28:28 +0000, John Hurley wrote: >> The linux bond itself registers a cb for offloading tc rules. Potential >> slave netdevs on offload devices can then register with the bond for a >> further callback - this code is basically the same as registering for an >> egress dev offload in TC. Then when a rule is offloaded to the bond, it >> can be relayed to each netdev that has registered with the bond code and >> which is a slave of the given bond. > > As you know I would much rather see this handled in the TC core, > similarly to how blocks are shared. We can add a new .ndo_setup_tc > notification like TC_MASTER_BLOCK_BIND and reuse the existing offload > tracking. It would also fix the problem of freezing the bond and allow > better code reuse with team etc.
+1 to handle this in tc core. We will soon find that many other devices will need to propagate rules down the netdev stack and keeping it in tc core allows re-use like you state above. The switchdev api's before they moved to notifiers in many cases had bond and other netdev stack offload traversal inside the switchdev layer (In the notifier world, I think a driver can still register and track rules and other offload on bonds with its own ports as slaves)
