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 15:01:33 -0700 Message-ID: <20180524150133.50ce88d1@cakuba> References: <20180524022255.18548-1-jakub.kicinski@netronome.com> <20180524114929.0fb4e38f@cakuba> 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-qt0-f170.google.com ([209.85.216.170]:42102 "EHLO mail-qt0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S971746AbeEXWBj (ORCPT ); Thu, 24 May 2018 18:01:39 -0400 Received: by mail-qt0-f170.google.com with SMTP id c2-v6so4118171qtn.9 for ; Thu, 24 May 2018 15:01:39 -0700 (PDT) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Thu, 24 May 2018 22:26:03 +0300, Or Gerlitz wrote: > On Thu, May 24, 2018 at 9:49 PM, Jakub Kicinski > wrote: > > On Thu, 24 May 2018 20:04:56 +0300, Or Gerlitz wrote: > > >> 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. > > To make it clear, vf lag is code name for uplink lag, I think we want > to say that we provide the VM a lagged VF, anyway, again, the lag is > done on the uplink reps not on the vf reps. Ah, ack, same use case here! > Unlike the uplink port which is physical one, the vf vport is virtual > one, what could be the benefit to bond two vports? I'm not sure what it could be :) We can also bond an uplink and a VF! All outputs on the nfp are working same, so why limit ourselves if we can do it? :)