Re: New commands to configure IOV features

[Don Dutile <ddutile@redhat.com>]

On 09/23/2012 11:49 AM, Yuval Mintz wrote:
>>>> It provides 3 sysfs files (enable, disable, num_max_vfs);
>>>> callbacks for enable&   disable.
>>>
>>> why using three? only pass max_vfs should be enough...
>>>
>>> aka pass 0 mean disabling, pass other value mean enabling.
>>>
>> could do that.  but I wouldn't use 'max_vfs'; I would recommend
>> 'num_vfs', as max implies, er, um, the maximum, and what one
>> wants is to be able to enable a number from 1->max_vfs.
>> 'max_vfs' will be provided by another file.
>>
>
> If we're at it, how do you suggest the configurations of the VFs
> resources/properties should be made?
> Notice I'm asking about properties which relate to all PCI devices,
> E.g., number of interrupts assigned to each VF (for VF RSS).
>
This issue/question is indep of VFs & SRIOV.
It's a generic problem for PFs and how many (msi) intr's a device
is given, based on its request, i.e., system provides 8 MSI per cpu
per device ... how are those 8 assigned/used by the device? ...
how to free 4 of the 8 if one device doesn't use them, and another
device could use them..   cache/memory affinity to intr's.... the list
goes on...

> (For properties which relate only to networking devices, we could
> use standard network API such as netlink).
>
> Perhaps given a configurable property that applies to all PCI devices,
A VF is 'just another PCI device', so configurable properties
for all PCI devices should encompass VF/SRIOV devices equally.

> once SRIOV is enabled and the VFs are created, there would be an
> additional sysfs node under the VFs through which the user could
> configure that property.
>
>
> --
> 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