From mboxrd@z Thu Jan 1 00:00:00 1970 From: Or Gerlitz Subject: Re: [PATCH net-next 0/8] nfp: offload LAG for tc flower egress Date: Thu, 24 May 2018 22:26:03 +0300 Message-ID: References: <20180524022255.18548-1-jakub.kicinski@netronome.com> <20180524114929.0fb4e38f@cakuba> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: David Miller , Linux Netdev List , oss-drivers@netronome.com, Jiri Pirko , Jay Vosburgh , Veaceslav Falico , Andy Gospodarek To: Jakub Kicinski Return-path: Received: from mail-ot0-f196.google.com ([74.125.82.196]:39978 "EHLO mail-ot0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161181AbeEXT0E (ORCPT ); Thu, 24 May 2018 15:26:04 -0400 Received: by mail-ot0-f196.google.com with SMTP id n1-v6so3303314otf.7 for ; Thu, 24 May 2018 12:26:04 -0700 (PDT) In-Reply-To: <20180524114929.0fb4e38f@cakuba> Sender: netdev-owner@vger.kernel.org List-ID: 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. Unlike the uplink port which is physical one, the vf vport is virtual one, what could be the benefit to bond two vports?