On Thu, Oct 4, 2018 at 7:55 AM Jakub Kicinski <jakub.kicin...@netronome.com> wrote: > > Hi! > > This set contains a rough RFC implementation of a proposed [1] replacement > for egdev cls_flower offloads. I did some last minute restructuring > and removal of parts I felt were unnecessary, so if there are glaring bugs > they are probably mine, not John's :) but hopefully this will give an idea > of the general direction. We need to beef up the driver part to see how > it fully comes together. > > [1] http://vger.kernel.org/netconf2018_files/JakubKicinski_netconf2018.pdf > slides 10-13 > > John's says: > > This patchset introduces as an alternative to egdev offload by allowing a > driver to register for block updates when an external device (e.g. tunnel > netdev) is bound to a TC block.
In a slightly different but hopefully somehow related context, regarding the case of flow offloading in the presence of upper devices (specifically LAG), your ovs user patch [1] applied TC block sharing on the slave of lag (bond/team) device which serves as ovs port. This way, flows that are installed on the bond are propagated to both uplink devices - good! However, when tunneling comes into play, the bond device is not part of the virtual switch but rather the tunnel device, so the SW DP is wire --> hw driver --> bond --> stack --> tunnel driver --> virtual switch So now, if the HW driver uses your new facility to register for rules installed on the tunnel device, we are again properly sharing (duplicating) the rules to both uplinks, right?! [1] d22f892 netdev-linux: monitor and offload LAG slaves to TC > Drivers can track new netdevs or register > to existing ones to receive information on such events. Based on this, > they may register for block offload rules using already existing functions. Just to make it clear, (part of) the claim to fame here is that once we have this code in, we can just go and remove all the egdev related code from the kernel (both core and drivers), right? only nfp and mlx5 use egdev, so the removal should be simple exercise. > Included with this RFC is a patch to the NFP driver. This is only supposed > to provide an example of how the remote block setup can be used. We will look and play with the patches next week and provide feedback, cool that you took the lead to improve the facilities here!
