Re: [RFC PATCH] virtio_net: Extend virtio to use VF datapath when available

On Tue, 19 Dec 2017 14:37:50 -0800
"Samudrala, Sridhar" [off-list ref] wrote:

On 12/19/2017 11:46 AM, Stephen Hemminger wrote:

quoted

On Tue, 19 Dec 2017 11:42:33 -0800
"Samudrala, Sridhar" [off-list ref] wrote:
 

quoted

On 12/19/2017 10:41 AM, Stephen Hemminger wrote:  

quoted

On Tue, 19 Dec 2017 13:21:17 -0500 (EST)
David Miller [off-list ref] wrote:
    

quoted

From: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue, 19 Dec 2017 09:55:48 -0800
    

quoted

could be 10ms, just enough to let udev do its renaming  

Please, move to some kind of notification or event based handling of
this problem.

No delay is safe, what if userspace gets swapped out or whatever
else might make userspace stall unexpectedly?
    

The plan is to remove the delay and do the naming in the kernel.
This was suggested by Lennart since udev is only doing naming policy
because kernel names were not repeatable.

This makes the VF show up as "ethN_vf" on Hyper-V which is user friendly.

Patch is pending.  

Do we really need to delay the setup until the name is changed?
Can't we call dev_set_mtu() and dev_open() until dev_change_name() is done?

Thanks
Sridhar  

You can call dev_set_mtu, but when dev_open is done the device name
can not be changed by userspace.  

I did a quick test to remove the delay and also the dev_open() call and 
i don't see
any issues with virtio taking over the VF datapath.
Only the netdev_info() messages may show old device name.

Any specific scenario where we need to explicitly call  VF's dev_open() 
in the VF setup process?
I tried i40evf driver loaded after virtio_net  AND  virtio_net loading 
after i40evf.

Thanks
Sridhar

It happens with hotplug. It is possible on Hyper-V to hotplug SR-IOV on
and off while guest is running. If SR-IOV is disabled in host then the
VF device is removed (hotplug) and the inverse. If the master device is
up then the VF device should be brought up by the master device.