Samudrala, Sridhar
2017-Dec-19 22:37 UTC
[RFC PATCH] virtio_net: Extend virtio to use VF datapath when available
On 12/19/2017 11:46 AM, Stephen Hemminger wrote:> On Tue, 19 Dec 2017 11:42:33 -0800 > "Samudrala, Sridhar" <sridhar.samudrala at intel.com> wrote: > >> On 12/19/2017 10:41 AM, Stephen Hemminger wrote: >>> On Tue, 19 Dec 2017 13:21:17 -0500 (EST) >>> David Miller <davem at davemloft.net> wrote: >>> >>>> From: Stephen Hemminger <stephen at networkplumber.org> >>>> Date: Tue, 19 Dec 2017 09:55:48 -0800 >>>> >>>>> 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
Stephen Hemminger
2017-Dec-19 22:53 UTC
[RFC PATCH] virtio_net: Extend virtio to use VF datapath when available
On Tue, 19 Dec 2017 14:37:50 -0800 "Samudrala, Sridhar" <sridhar.samudrala at intel.com> wrote:> On 12/19/2017 11:46 AM, Stephen Hemminger wrote: > > On Tue, 19 Dec 2017 11:42:33 -0800 > > "Samudrala, Sridhar" <sridhar.samudrala at intel.com> wrote: > > > >> On 12/19/2017 10:41 AM, Stephen Hemminger wrote: > >>> On Tue, 19 Dec 2017 13:21:17 -0500 (EST) > >>> David Miller <davem at davemloft.net> wrote: > >>> > >>>> From: Stephen Hemminger <stephen at networkplumber.org> > >>>> Date: Tue, 19 Dec 2017 09:55:48 -0800 > >>>> > >>>>> 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 > SridharIt 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.
Samudrala, Sridhar
2017-Dec-20 00:26 UTC
[RFC PATCH] virtio_net: Extend virtio to use VF datapath when available
On 12/19/2017 2:53 PM, Stephen Hemminger wrote:> On Tue, 19 Dec 2017 14:37:50 -0800 > "Samudrala, Sridhar" <sridhar.samudrala at intel.com> wrote: > >> On 12/19/2017 11:46 AM, Stephen Hemminger wrote: >>> On Tue, 19 Dec 2017 11:42:33 -0800 >>> "Samudrala, Sridhar" <sridhar.samudrala at intel.com> wrote: >>> >>>> On 12/19/2017 10:41 AM, Stephen Hemminger wrote: >>>>> On Tue, 19 Dec 2017 13:21:17 -0500 (EST) >>>>> David Miller <davem at davemloft.net> wrote: >>>>> >>>>>> From: Stephen Hemminger <stephen at networkplumber.org> >>>>>> Date: Tue, 19 Dec 2017 09:55:48 -0800 >>>>>> >>>>>>> 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. >> > 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.Even with KVM, we need to hot unplug SR-IOV device on the source host and? plug it back on the destination host to enable live migration. It all works for me even without the dev_open() of the lower device? from the VF setup routine. Will send out a v2 version of this patch without the delayed VF setup after some more testing next week. Thanks Sridhar
Reasonably Related Threads
- [RFC PATCH] virtio_net: Extend virtio to use VF datapath when available
- [RFC PATCH] virtio_net: Extend virtio to use VF datapath when available
- [RFC PATCH] virtio_net: Extend virtio to use VF datapath when available
- [RFC PATCH] virtio_net: Extend virtio to use VF datapath when available
- [RFC PATCH] virtio_net: Extend virtio to use VF datapath when available