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

On Sun, Dec 07, 2014 at 05:05:06PM +0000, 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?

You can probe any VF at the hypervisor through sysfs files
(bind/unbind). You can also pass them through to a VM. Nothing
changes.

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

Sorry, I don't follow you here. Please clarify.

To be clear, the functionality proposed here is really one shot. It
just prevents calling probe once; besides that nothing changes.

  reply	other threads:[~2014-12-07 18:42 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 [this message]
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
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=20141207184242.GA24790@mtldesk30 \
    --to=eli@dev.mellanox.co.il \
    --cc=Yuval.Mintz@qlogic.com \
    --cc=bhelgaas@google.com \
    --cc=davem@davemloft.net \
    --cc=ddutile@redhat.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.