From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Kicinski Subject: Re: [PATCH net-next 0/8] nfp: offload LAG for tc flower egress Date: Thu, 24 May 2018 11:49:29 -0700 Message-ID: <20180524114929.0fb4e38f@cakuba> References: <20180524022255.18548-1-jakub.kicinski@netronome.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: David Miller , Linux Netdev List , oss-drivers@netronome.com, Jiri Pirko , Jay Vosburgh , Veaceslav Falico , Andy Gospodarek To: Or Gerlitz Return-path: Received: from mail-qk0-f196.google.com ([209.85.220.196]:35142 "EHLO mail-qk0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1032876AbeEXStd (ORCPT ); Thu, 24 May 2018 14:49:33 -0400 Received: by mail-qk0-f196.google.com with SMTP id h140-v6so2136317qke.2 for ; Thu, 24 May 2018 11:49:33 -0700 (PDT) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Thu, 24 May 2018 20:04:56 +0300, Or Gerlitz wrote: > On Thu, May 24, 2018 at 5:22 AM, Jakub Kicinski 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 I don't think we have a limitation on the output port within the LAG. But keep in mind in our devices all ports belong to the same eswitch/PF so bonding uplink ports is generally sufficient, I'm not sure VF bonding adds much HA. IOW AFAIK we support VF bonding because HW can do it easily, not because we have a strong use case for it.