search for: ethn_vf

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?

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?

...>> 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

...>> 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

...gt; 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 dele...

...gt; 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 dele...

...ly? >>>> >>> 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 c...

...ly? >>>> >>> 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 c...

...ce 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 wh...

...gt; >>> 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? > >> > >> Th...

...2017 18:16:30 -0800, Siwei Liu wrote: > > 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 whe...

...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.