On Thu, Feb 22, 2018 at 5:07 AM, Jiri Pirko [off-list ref] wrote:

Thu, Feb 22, 2018 at 12:54:45PM CET, gerlitz.or@gmail.com wrote:

quoted

On Thu, Feb 22, 2018 at 10:11 AM, Jiri Pirko [off-list ref] wrote:

quoted

Wed, Feb 21, 2018 at 09:57:09PM CET, alexander.duyck@gmail.com wrote:

quoted

quoted

The signaling isn't too much of an issue since we can just tweak the
link state of the VF or virtio manually to report the link up or down
prior to the hot-plug. Now that we are on the same page with the team0

quoted

Oh, so you just do "ip link set vfrepresentor down" in the host.
That makes sense. I'm pretty sure that this is not implemented for all
drivers now.

mlx5 supports that, on the representor close ndo we take the VF link
operational v-link down

We should probably also put into the picture some/more aspects
from the host side of things. The provisioning of the v-switch now
have to deal with two channels going into the VM, the PV (virtio)
one and the PT (VF) one.

This should probably boil down to apply teaming/bonding between
the VF representor and a PV backend device, e.g TAP.

Yes, that is correct.

That was my thought on it. If you wanted to you could probably even
look at making the PV the active one in the pair from the host side if
you wanted to avoid the PCIe overhead for things like
broadcast/multicast. The only limitation is that you might need to
have the bond take care of the appropriate switchdev bits so that you
still programmed rules into the hardware even if you are transmitting
down the PV side of the device.

For legacy setups I still need to work on putting together a source
mode macvlan based setup to handle acting like port representors for
the VFs and uplink.

- Alex