Re: Re: [PATCH v4 2/2] virtio_net: Extend virtio to use VF datapath when available

On Fri, Mar 02, 2018 at 12:56:21PM -0800, Samudrala, Sridhar wrote:

On 3/2/2018 12:44 PM, Siwei Liu wrote:

quoted

On Fri, Mar 2, 2018 at 12:10 PM, Michael S. Tsirkin [off-list ref] wrote:

quoted

On Fri, Mar 02, 2018 at 11:52:27AM -0800, Samudrala, Sridhar wrote:

quoted

On 3/2/2018 11:41 AM, Michael S. Tsirkin wrote:

quoted

On Fri, Mar 02, 2018 at 07:26:25AM -0800, Alexander Duyck wrote:

quoted

The design limits things to a 1:1 relationship since we just have the
child and backup pointers, but I don't think I am seeing exception
handling to prevent us from overwriting the child pointers so there
may be a leak there.

Thanks.

- Alex

In fact maintaining a list in that case would be nicer, and
just use an arbitrary one.
E.g. one can see how a user wanting to swap device 1 for device 2
might first add device 2 with same MAC then drop device 1.

It should be possible to swap VF1 with VF2 by
1.- enabling virtio link
2.- unplugging VF1
3.- plugging VF2
4.- disabling virtio link

True, but it isn't hard to avoid breakage if user
swapped steps 2 and 3. No need to make it more
fragile that it has to be.

The migration case, VF2 is associated with another PF on another
machine (destination), I wonder how it is possible.

Even with local plugging of VF2 on the same PF, the MAC address
requirement (VF1's == VF2's) would fail the MAC address assignment on
VF2.

I didn't include updating the MAC filter step in the above sequence.
So definitely plugging 2 VFs with the same MAC address will be an issue.

If these are two separate PFs then I don't see why -
each has its own MAC filter.

Here is the more complete sequence of steps that are required to
enable live migration.

Replacing VF1 by VF2 is not about migration. It's to remove PF
from host e.g. for service.

-- 
MST