All of lore.kernel.org
 help / color / mirror / Atom feed
From: Saeed Mahameed <saeedm@mellanox.com>
To: Roi Dayan <roid@mellanox.com>, Mark Bloch <markb@mellanox.com>,
	"schnelle@linux.ibm.com" <schnelle@linux.ibm.com>,
	Moshe Shemesh <moshe@mellanox.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"leon@kernel.org" <leon@kernel.org>
Subject: Re: [PATCH 0/1] net/mlx5: Call pci_disable_sriov() on remove
Date: Thu, 30 Apr 2020 16:13:34 +0000	[thread overview]
Message-ID: <08d0c332f3cfa034dddc2e3321bf7649ab718701.camel@mellanox.com> (raw)
In-Reply-To: <20200430120308.92773-1-schnelle@linux.ibm.com>

On Thu, 2020-04-30 at 14:03 +0200, Niklas Schnelle wrote:
> Hello,
> 
> I'm currently working on improvements in PF-VF handling on s390. One
> thing that
> may be a bit special for us is that the s390 hotplug code supports
> shutting
> down a single PF of a multi-function device such as a ConnectX-5.
> During testing I found that the mlx5_core driver does not call
> pci_disable_sriov() in its remove handler which is called on the PF
> via
> pci_stop_and_remove_bus_device() on an orderly hot unplug.

Actually what happens if you call pci_disable_sriov() when there are
VFs attached to VMs ? 

> 
> Following is a patch to fix this, I want to point out however that
> I'm not
> entirely sure about the effect of clear_vfs that distinguishes
> mlx5_sriov_detach() from mlx5_sriov_disable() only that the former is
> called
> from the remove handler and it doesn't call pci_disable_sriov().
> That however is required according to Documentation/PCI/pci-iov-
> howto.rst
> 

The Doc doesn't say "required", so the question is, is it really
required ? 

because the way i see it, it is the admin responsibility to clear out
vfs before shutting down the PF driver.

as explained in the patch review, mlx5 vf driver is resilient of such
behavior and once the device is back online the vf driver quickly
recovers, so it is actually a feature and not a bug :)

There are many reasons why the admin would want to do this:

1) Fast Firmware upgrade
2) Fast Hyper-visor upgrade/refresh
3) PF debugging 

So you can quickly reset the PF driver without the need to wait for all
VFs or manually detach-attach them.


> I've only tested this on top of my currently still internal PF-VF
> rework so
> I might also be totally missing something here in that case excuse my
> ignorance.
> 
> Best regards,
> Niklas Schnelle
> 
> Niklas Schnelle (1):
>   net/mlx5: Call pci_disable_sriov() on remove
> 
>  drivers/net/ethernet/mellanox/mlx5/core/sriov.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 

  parent reply	other threads:[~2020-04-30 16:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-30 12:03 [PATCH 0/1] net/mlx5: Call pci_disable_sriov() on remove Niklas Schnelle
2020-04-30 12:03 ` [PATCH 1/1] " Niklas Schnelle
2020-04-30 15:58   ` Saeed Mahameed
2020-04-30 19:47     ` Niklas Schnelle
2020-04-30 22:31       ` Niklas Schnelle
2020-04-30 16:13 ` Saeed Mahameed [this message]
2020-04-30 20:25   ` [PATCH 0/1] " Niklas Schnelle

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=08d0c332f3cfa034dddc2e3321bf7649ab718701.camel@mellanox.com \
    --to=saeedm@mellanox.com \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markb@mellanox.com \
    --cc=moshe@mellanox.com \
    --cc=netdev@vger.kernel.org \
    --cc=roid@mellanox.com \
    --cc=schnelle@linux.ibm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.