netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Yinjun Zhang <yinjun.zhang@corigine.com>
Cc: Saeed Mahameed <saeed@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>,
	Simon Horman <simon.horman@corigine.com>,
	David Miller <davem@davemloft.net>,
	Paolo Abeni <pabeni@redhat.com>,
	Michael Chan <michael.chan@broadcom.com>,
	Andy Gospodarek <andy@greyhouse.net>,
	Gal Pressman <gal@nvidia.com>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	Edward Cree <ecree.xilinx@gmail.com>,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Nole Zhang <peng.zhang@corigine.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	oss-drivers <oss-drivers@corigine.com>
Subject: Re: [PATCH net-next 0/3] nfp: support VF multi-queues configuration
Date: Thu, 27 Oct 2022 08:53:49 +0300	[thread overview]
Message-ID: <Y1oc7dRrKeuQbLId@unreal> (raw)
In-Reply-To: <DM6PR13MB370531053A394EE41080158FFC339@DM6PR13MB3705.namprd13.prod.outlook.com>

On Thu, Oct 27, 2022 at 02:11:55AM +0000, Yinjun Zhang wrote:
> On Wed, 26 Oct 2022 15:22:21 +0100, Saeed Mahameed wrote:
> > On 25 Oct 11:39, Yinjun Zhang wrote:
> > >On Date: Tue, 25 Oct 2022 12:05:14 +0100, Saeed Mahameed wrote:
> > 
> > Usually you create the VFs unbound, configure them and then bind them.
> > otherwise a query will have to query any possible VF which for some vendors
> > can be thousands ! it's better to work on created but not yet deployed vfs
> 
> Usually creating and binding are not separated, that's why `sriov_drivers_autoprobe`
> is default true.

No, the situation is completely an opposite in a world which heavily uses SR-IOV.
Data centers which rely on SR-IOV to provide VMs to customers separate creation and
bind, as they two different stages in container/VM lifetime. Create is done when
physical server is booted and bind is done when user requested specific properties
of VM.

Various container orchestration frameworks do it for them.

> that's why `sriov_drivers_autoprobe` is default true.

It is not true either. The default value is chosen to keep kernel
backward compatible behavior. 

> unless some particular configuration requires it, like mlnx's msix
> practice. 

And it is not true either. I did MLNX implementation to be aligned with
PCI spec and in-kernel PCI subsystem implementation. Our device can change
MSI-X on-fly and from HW perspective unbind is not important.

Saeed is right "Usually you create the VFs unbound, configure them and
then bind them".

Thanks

  reply	other threads:[~2022-10-27  5:53 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-19 14:09 [PATCH net-next 0/3] nfp: support VF multi-queues configuration Simon Horman
2022-10-19 14:09 ` [PATCH net-next 1/3] " Simon Horman
2022-10-19 14:09 ` [PATCH net-next 2/3] devlink: Add new "max_vf_queue" generic device param Simon Horman
2022-10-23 11:28   ` Gal Pressman
2022-10-24  1:47     ` Yinjun Zhang
2022-10-24  8:36       ` Leon Romanovsky
2022-10-19 14:09 ` [PATCH net-next 3/3] nfp: devlink: add the devlink parameter "max_vf_queue" support Simon Horman
2022-10-20  1:01 ` [PATCH net-next 0/3] nfp: support VF multi-queues configuration Jakub Kicinski
2022-10-20  1:35   ` Yinjun Zhang
2022-10-25  7:51     ` Saeed Mahameed
2022-10-25 10:41       ` Yinjun Zhang
2022-10-25 11:05         ` Saeed Mahameed
2022-10-25 11:39           ` Yinjun Zhang
2022-10-26 14:22             ` Saeed Mahameed
2022-10-26 20:07               ` Jakub Kicinski
2022-10-26 22:25                 ` Saeed Mahameed
2022-10-27  2:11               ` Yinjun Zhang
2022-10-27  5:53                 ` Leon Romanovsky [this message]
2022-10-27  6:01                 ` Leon Romanovsky
2022-10-27  8:46                 ` Saeed Mahameed
2022-10-27  9:46                   ` Yinjun Zhang
2022-10-27 10:49                     ` Saeed Mahameed
2022-10-29  3:32                       ` Yinjun Zhang

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=Y1oc7dRrKeuQbLId@unreal \
    --to=leon@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=andy@greyhouse.net \
    --cc=anthony.l.nguyen@intel.com \
    --cc=davem@davemloft.net \
    --cc=ecree.xilinx@gmail.com \
    --cc=gal@nvidia.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=kuba@kernel.org \
    --cc=michael.chan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=oss-drivers@corigine.com \
    --cc=pabeni@redhat.com \
    --cc=peng.zhang@corigine.com \
    --cc=saeed@kernel.org \
    --cc=simon.horman@corigine.com \
    --cc=vladimir.oltean@nxp.com \
    --cc=yinjun.zhang@corigine.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 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).