On Thu, Oct 4, 2018 at 8:19 PM Jakub Kicinski <jakub.kicin...@netronome.com> wrote: > On Thu, 4 Oct 2018 17:20:43 +0100, John Hurley wrote: > > > > In this case the hw driver will receive the rules from the tunnel > > > > device directly. > > > > The driver can then offload them as it sees fit. > > > > > > if both instances of the hw drivers (uplink0, uplink1) register to get > > > the rules installed on the block of the tunnel device we have exactly > > > what we want, isn't that? > > > > > > > The design here is that each hw driver should only need to register > > for callbacks on a 'higher level' device's block once. > > When a callback is triggered the driver receives one instance of the > > rule and can make its own decision about what to do. > > This is slightly different from registering ingress devs where each > > uplink registers for its own block. > > It is probably more akin to the egdev setup in that if a rule on a > > block egresses to an uplink, the driver receives 1 callback on the > > rule, irrespective of how may underlying netdevs are on the block. > > Right, though nothing stops the driver from registering multiple > callbacks for the same device, if its somehow useful.
I must be missing something.. put uplink bonding a side. If the user is setting tc ingress rule on a tunnel device (vxlan0/gre0) over a system with multiple unrelated NICs/uplinks that support TC decap offload, wouldn't each of these netdevs want to install the rule into HW? why do we want the HW driver to duplicate the rule between the potential candidates among the netdev instances they created? and not each of them to get the callback and decide?? we want each netdev instance of these NIC
