All of lore.kernel.org
 help / color / mirror / Atom feed
From: Don Dutile <ddutile@redhat.com>
To: Yuval Mintz <Yuval.Mintz@qlogic.com>,
	Eli Cohen <eli@dev.mellanox.co.il>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	David Miller <davem@davemloft.net>
Cc: linux-pci <linux-pci@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>,
	"ogerlitz@mellanox.com" <ogerlitz@mellanox.com>,
	"yevgenyp@mellanox.com" <yevgenyp@mellanox.com>,
	Eli Cohen <eli@mellanox.com>
Subject: Re: [PATCH RFC] pci: Control whether VFs are probed on pci_enable_sriov
Date: Sun, 07 Dec 2014 16:32:45 -0500	[thread overview]
Message-ID: <5484C77D.7060501@redhat.com> (raw)
In-Reply-To: <B5657A6538887040AD3A81F1008BEC63BA6616@avmb3.qlogic.org>

On 12/07/2014 12:05 PM, Yuval Mintz wrote:
>
>> This can save host side resource usage by VF instances which would be
>> eventually probed to VMs.
>
>> Use a parameter to pci_enable_sriov to control that policy, and modify
>> all current callers such that they retain the same functionality.
>
> What's the end-game here? How eventually would this be controlled?
>
>> Use a one shot flag on struct pci_device which is cleared after the
>> first probe is ignored so subsequent attempts go through.
>
> Does a one-shot flag suffice? E.g., consider assigning a VF to VM and
> than shutting down the VM. Assuming this feature is disabled,
> the VF didn't appear on the hypervisor prior to the assignment but
> will appear after its shutdown.
>
+1 to this question.
All I see is a one-shot savings in VF configuration time at pci_sriov_enable() time.
Please explain why this is so important for mlx5 (sriov) operation?

Can the vf driver probe be called & exit early the first time, and perform full
(host) configuration thereafter?

- Don

  parent reply	other threads:[~2014-12-08  2:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-07 13:08 [PATCH RFC] pci: Control whether VFs are probed on pci_enable_sriov Eli Cohen
2014-12-07 17:05 ` Yuval Mintz
2014-12-07 18:42   ` Eli Cohen
2014-12-07 20:08     ` Yuval Mintz
2014-12-08 19:10       ` Eli Cohen
2014-12-08 19:25         ` Yuval Mintz
2014-12-09  6:43           ` Eli Cohen
2014-12-09  7:07             ` Yuval Mintz
2014-12-09 17:24               ` Don Dutile
2014-12-07 21:32   ` Don Dutile [this message]
2014-12-08 18:52     ` Eli Cohen
2015-01-09 18:25 ` Bjorn Helgaas
2015-01-09 18:38   ` Don Dutile

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=5484C77D.7060501@redhat.com \
    --to=ddutile@redhat.com \
    --cc=Yuval.Mintz@qlogic.com \
    --cc=bhelgaas@google.com \
    --cc=davem@davemloft.net \
    --cc=eli@dev.mellanox.co.il \
    --cc=eli@mellanox.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=ogerlitz@mellanox.com \
    --cc=yevgenyp@mellanox.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.