netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Samudrala, Sridhar" <sridhar.samudrala@intel.com>
Cc: David Miller <davem@davemloft.net>,
	mst@redhat.com, netdev@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	alexander.duyck@gmail.com, jesse.brandeburg@intel.com
Subject: Re: [RFC PATCH] virtio_net: Extend virtio to use VF datapath when available
Date: Tue, 19 Dec 2017 14:53:45 -0800	[thread overview]
Message-ID: <20171219145345.3c261273@xeon-e3> (raw)
In-Reply-To: <ddef3208-3cf5-faa2-7572-a561a6b35e2f@intel.com>

On Tue, 19 Dec 2017 14:37:50 -0800
"Samudrala, Sridhar" <sridhar.samudrala@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@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@davemloft.net> wrote:
> >>>     
> >>>> From: Stephen Hemminger <stephen@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

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.

  reply	other threads:[~2017-12-19 22:53 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-19  0:40 [RFC PATCH] virtio_net: Extend virtio to use VF datapath when available Sridhar Samudrala
2017-12-19 15:47 ` Michael S. Tsirkin
2017-12-19 17:41   ` Samudrala, Sridhar
2017-12-19 17:55     ` Stephen Hemminger
2017-12-19 18:07       ` Michael S. Tsirkin
2017-12-19 18:13         ` Stephen Hemminger
2017-12-19 18:21       ` David Miller
2017-12-19 18:41         ` Stephen Hemminger
2017-12-19 19:42           ` Samudrala, Sridhar
2017-12-19 19:46             ` Stephen Hemminger
2017-12-19 22:37               ` Samudrala, Sridhar
2017-12-19 22:53                 ` Stephen Hemminger [this message]
2017-12-20  0:26                   ` Samudrala, Sridhar
2017-12-21  1:31           ` Siwei Liu
2017-12-21  2:16           ` Siwei Liu
2017-12-21  4:52             ` Jakub Kicinski
2017-12-22  8:42               ` Siwei Liu
2017-12-19 18:20     ` David Miller
2017-12-20 10:51       ` Vitaly Kuznetsov
2017-12-20 22:33 ` Jakub Kicinski
2017-12-21  0:15   ` Michael S. Tsirkin
2017-12-21  0:29     ` Jakub Kicinski
2017-12-21  0:14 ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171219145345.3c261273@xeon-e3 \
    --to=stephen@networkplumber.org \
    --cc=alexander.duyck@gmail.com \
    --cc=davem@davemloft.net \
    --cc=jesse.brandeburg@intel.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=sridhar.samudrala@intel.com \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).