On Thu, 24 May 2018 22:26:03 +0300, Or Gerlitz wrote: > On Thu, May 24, 2018 at 9:49 PM, Jakub Kicinski > <jakub.kicin...@netronome.com> 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? :)
