[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <B5657A6538887040AD3A81F1008BEC63BA7746@avmb3.qlogic.org>
Date: Mon, 8 Dec 2014 19:25:24 +0000
From: Yuval Mintz <Yuval.Mintz@...gic.com>
To: Eli Cohen <eli@....mellanox.co.il>
CC: "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
David Miller <davem@...emloft.net>,
linux-pci <linux-pci@...r.kernel.org>,
netdev <netdev@...r.kernel.org>,
"ogerlitz@...lanox.com" <ogerlitz@...lanox.com>,
"yevgenyp@...lanox.com" <yevgenyp@...lanox.com>,
Donald Dutile <ddutile@...hat.com>
Subject: RE: [PATCH RFC] pci: Control whether VFs are probed on
pci_enable_sriov
>>>> 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.
>> If you're not planning on adding a logic to set this, why do we need to
>> add a parameter to pci_enable_sriov() - given that all callers use the
>> exact same logic?
>> [And I don't really think we'd want different devices to behave differently
>> by default; That would be confusing for users.]
>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.--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists