David Miller
2017-Dec-19 18:21 UTC
[RFC PATCH] virtio_net: Extend virtio to use VF datapath when available
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 renamingPlease, 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?
Stephen Hemminger
2017-Dec-19 18:41 UTC
[RFC PATCH] virtio_net: Extend virtio to use VF datapath when available
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.
Samudrala, Sridhar
2017-Dec-19 19:42 UTC
[RFC PATCH] virtio_net: Extend virtio to use VF datapath when available
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
Siwei Liu
2017-Dec-21 01:31 UTC
[RFC PATCH] virtio_net: Extend virtio to use VF datapath when available
On Tue, Dec 19, 2017 at 10:41 AM, Stephen Hemminger < stephen at networkplumber.org> 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. >While it's good to show VF with specific naming to indicate enslavement, I wonder wouldn't it be better to hide this netdev at all from the user space? IMHO this extra device is useless when being enslaved and we may delegate controls (e.g. ethtool) over to the para-virtual device instead? That way it's possible to eliminate the possibility of additional udev setup or modification? I'm not sure if this is consistent with Windows guest or not, but I don't find it _Linux_ user friendly that ethtool doesn't work on the composite interface any more, and I have to end up with finding out the correct enslaved VF I must operate on. Regards, -Siwei -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20171221/6474385c/attachment.html>
Siwei Liu
2017-Dec-21 02:16 UTC
[RFC PATCH] virtio_net: Extend virtio to use VF datapath when available
On Tue, Dec 19, 2017 at 10:41 AM, Stephen Hemminger <stephen at networkplumber.org> 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.While it's good to show VF with specific naming to indicate enslavement, I wonder wouldn't it be better to hide this netdev at all from the user space? IMHO this extra device is useless when being enslaved and we may delegate controls (e.g. ethtool) over to the para-virtual device instead? That way it's possible to eliminate the possibility of additional udev setup or modification? I'm not sure if this is consistent with Windows guest or not, but I don't find it _Linux_ user friendly that ethtool doesn't work on the composite interface any more, and I have to end up with finding out the correct enslaved VF I must operate on. Regards, -Siwei
Apparently Analagous 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