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: Tue, 9 Dec 2014 08:43:39 +0200 [thread overview]
Message-ID: <20141209064339.GA1806@mtldesk30> (raw)
In-Reply-To: <B5657A6538887040AD3A81F1008BEC63BA7746@avmb3.qlogic.org>
On Mon, Dec 08, 2014 at 07:25:24PM +0000, Yuval Mintz wrote:
>
> >Currently the kerenl will call probe for any device for which there is
> >a supporting driver and I did not want to change that.
>
> But what's next? How will this feature be activated?
>
> Adding a parameter to pci_enable_sriov() might give developers the false
> impression they can change behavior by passing `0' to this function;
> But that shouldn't be the method to control this - we should have uniform
> control of the feature across different drivers, e.g., by an additional sysfs node.
I was planning on using this on mlx5 SRIOV support which is not
available upstream yet. So this could be a driver developer's decision
how to use this. I think adding another sysfs entry to control this
behavior is unnecessary since the administrator has the freedom to
later do any bidnings he wishes to do.
Keeping things as they are today is not so "nice". I mean, I could
fail probe for VFs to avoid them from being initialized at the
hypervisor but there are other questions: which error should I return
and how can I be sure how the bus driver will refer to such failures.
So, maybe the solution I suggested is not the best one but do we agree
that this needs to be addressed this way or another?
next prev parent reply other threads:[~2014-12-09 6:43 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 [this message]
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=20141209064339.GA1806@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 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).