On Thu, Feb 22, 2018 at 5:07 AM, Jiri Pirko <j...@resnulli.us> wrote:
> Thu, Feb 22, 2018 at 12:54:45PM CET, gerlitz...@gmail.com wrote:
>>On Thu, Feb 22, 2018 at 10:11 AM, Jiri Pirko <j...@resnulli.us> wrote:
>>> Wed, Feb 21, 2018 at 09:57:09PM CET, alexander.du...@gmail.com wrote:
>>>>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
>>> 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.