On Thu, 24 May 2018 11:23:00 -0700, Samudrala, Sridhar wrote: > On 5/24/2018 10:04 AM, Or Gerlitz wrote: > > On Thu, May 24, 2018 at 5:22 AM, Jakub Kicinski > > <jakub.kicin...@netronome.com> wrote: > >> Hi! > >> > >> This series from John adds bond offload to the nfp driver. Patch 5 > >> exposes the hash type for NETDEV_LAG_TX_TYPE_HASH to make sure nfp > >> hashing matches that of the software LAG. This may be unnecessarily > >> conservative, let's see what LAG maintainers think :) > >> > >> John says: > >> > >> This patchset sets up the infrastructure and offloads output actions for > >> when a TC flower rule attempts to egress a packet to a LAG port. > >> > >> Firstly it adds some of the infrastructure required to the flower app and > >> to the nfp core. This includes the ability to change the MAC address of a > >> repr, a function for combining lookup and write to a FW symbol, and the > >> addition of private data to a repr on a per app basis. > >> > >> Patch 6 continues by implementing notifiers that track Linux bonds and > >> communicates to the FW those which enslave reprs, along with the current > >> state of reprs within the bond. > >> > >> Patch 7 ensures bonds are synchronised with FW by receiving and acting > >> upon cmsgs sent to the kernel. These may request that a bond message is > >> retransmitted when FW can process it, or may request a full sync of the > >> bonds defined in the kernel. > >> > >> Patch 8 offloads a flower action when that action requires egressing to a > >> pre-defined Linux bond. > > Does this apply also to non-uplink representors? if yes, what is the use > > case? > > > > We are looking on supporting uplink lag in sriov switchdev scheme - we > > refer to > > it as "vf lag" -- b/c the netdev and rdma devices seen by the VF are > > actually > > subject to HA and/or LAG - I wasn't sure if/how you limit this series > > to uplink reprs > > Also, does this patchset support offloading LAG when using vxlan based > tunnels? > > When using OVS offloading with vxlan, the encap rule that gets offloaded via > tc-flower > has egress port as vxlan device and the decap rule has the in-port as vxlan > device, not > the actual egress port. How are you addressing this issue?
It is very much on our radar, I think we will send out a related RFC later today :) But to be honest I think you can just install an egress callback on the bond and that will pretty much work today. You don't have to "own" the egress device to install a egdev callback on it.
