From: Don Dutile <ddutile@redhat.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Yinghai Lu <yinghai@kernel.org>, Jon Mason <jdmason@kudzu.us>,
Jiang Liu <liuj97@gmail.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: PCI mini-summit notes
Date: Tue, 04 Sep 2012 21:41:48 -0400 [thread overview]
Message-ID: <5046ADDC.8090707@redhat.com> (raw)
In-Reply-To: <5046ABE0.303@redhat.com>
On 09/04/2012 09:33 PM, Don Dutile wrote:
> On 08/30/2012 02:02 AM, Bjorn Helgaas wrote:
>> [removed cc ksummit-2012-discuss]
>>
>> On Wed, Aug 29, 2012 at 3:54 PM, Yinghai Lu<yinghai@kernel.org> wrote:
>>> On Wed, Aug 29, 2012 at 3:44 PM, Jon Mason<jdmason@kudzu.us> wrote:
>>>>> Hi Bjorn,
>>>>> One of my team member reported another corner case for SR-IOV. There's
>>>>> are two NIC cards in the system driven by the same driver, but one supports
>>>>> SR-IOV and the other doesn't. It runs into trouble if "max_vfs" parameter is
>>>>> set for the NIC driver.
>>>>> --Gerry
>>>>
>>>> I believe it was decided that a per-pf sysfs interface would be used
>>>> to replace the current module parameter that specifies the number of
>>>> vf's. This should enable different numbers of vf's for each physical
>>>> device. The driver interface that was discussed would introduce new
>>>> function pointers for handlers to setup/teardown the vf's. I believe
>>>> this will solve your problem once it has been implemented.
>>>
>>> now we have ixgbe.max_vfs=63
>>>
>>> so if change to per pci device (PF),
>>>
>>> how about having the driver built-in?
>>> what kind of kernel parameters will be passed?
>
> Having the driver built-in won't make a difference.
>
> The model is to have files under sys fs, i.e.,
> /sys/bus/pci/devices/0000:03:01.0/[sriov_vf_enable, sriov_vf_disable]
>
> where one echo's the number of vf's one wants to configure for a pf
> into the sriov_vf_enable file; if want to disable/deconfigure the vf's,
> one echo's a 1 to sriov_vf_disable (all or nothing disable).
>
> the pci core will be able to check & filter that the max num of vf's
> is not exceeded. Also looking to add a file like 'sriov_num_vfs' to
> indicate max number of vf's a PF supports. Whether the bus configuration
> supports it (enough mmio space, enough pci bus nums, etc.) won't be
> known until the enable count is written.
>
> I have the code down to create the sysfs files & report the num_vfs.
^^^^ should be 'done' ...
> Hope to have the first enable/disable working within another week.
> The tough part is to re-factor a pf driver that enables/configures pf;
> I'm working with the igb(_main.c) driver right now.
>
> - Don
btw -- what we didn't resolve at summit, and I haven't taken a crack at it yet,
is a method to set the vf-enablement on a per-pf basis at boot time...
-- kernel cmdline (sounds knarly for large PCIe config)
-- /etc/module.d/sriov.conf ?
-- other ?
>>
>> I don't think we really discussed things at this level, and I
>> personally don't know enough about the current SR-IOV support to even
>> know what the possible strategies are. I think it's really up to the
>> person doing the implementation to figure out what makes sense given
>> the constraints of the SR-IOV specs and the current Linux support.
>>
>> Bjorn
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
next prev parent reply other threads:[~2012-09-05 1:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-29 7:28 PCI mini-summit notes Bjorn Helgaas
2012-08-29 15:48 ` Jiang Liu
2012-08-29 22:44 ` Jon Mason
2012-08-29 22:54 ` Yinghai Lu
2012-08-30 6:02 ` Bjorn Helgaas
2012-09-05 1:33 ` Don Dutile
2012-09-05 1:41 ` Don Dutile [this message]
2012-09-03 8:51 ` Ram Pai
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=5046ADDC.8090707@redhat.com \
--to=ddutile@redhat.com \
--cc=bhelgaas@google.com \
--cc=jdmason@kudzu.us \
--cc=linux-pci@vger.kernel.org \
--cc=liuj97@gmail.com \
--cc=yinghai@kernel.org \
/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.