On Mon, Mar 5, 2018 at 9:43 PM, Or Gerlitz <gerlitz...@gmail.com> wrote: > On Mon, Mar 5, 2018 at 3:28 PM, John Hurley <john.hur...@netronome.com> wrote: >> This RFC patchset adds support for offloading tc ingress rules applied to >> linux bonds. The premise of these patches is that if a rule is applied to >> a bond port then the rule should be applied to each slave of the bond. >> >> 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. >> >> To prevent sync issues between the kernel and offload device, the linux >> bond driver is affectively locked when it has offloaded rules. i.e no new >> ports can be enslaved and no slaves can be released until the offload >> rules are removed. Similarly, if a port on a bond is deleted, the bond is >> destroyed, forcing a flush of all offloaded rules. >> >> Also included in the RFC are changes to the NFP driver to utilise the new >> code by registering NFP port representors for bond offload rules and >> modifying cookie handling to allow the relaying of a rule to multiple ports. > > what is your approach for rules whose bond is their egress device > (ingress = vf port > representor)?
Egress offload will be handled entirely by the NFP driver. Basically, notifiers will track the slaves/masters and update the card with any groups that consist entirely of reprs. We then offload the TC rule outputting to the given group - because it is an ingress match we can access the egress netdev in the block callback.
