On Wed, Mar 6, 2013 at 5:28 PM,  <narendr...@dell.com> wrote:
>> -----Original Message-----
>> From: devel-boun...@lists.fedoraproject.org [mailto:devel-
>> boun...@lists.fedoraproject.org] On Behalf Of Michal Schmidt
>> Sent: Tuesday, March 05, 2013 10:22 PM
>> To: devel@lists.fedoraproject.org
>> Subject: Re: Proposed F19 Feature: systemd/udev Predictable Network
>> Interface Names
>>
>> On 03/04/2013 04:01 PM, Matt Domsch wrote:
>> > drivers/net/ethernet/sfc/siena.c:       efx->net_dev->dev_id =
>> EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1;
>>
>> I think sfc does not really *need* to set dev_id.
>> Yes, these are multi-port cards, but the ports are on distinct PCI functions.
>>
>
> I think setting of 'dev_id' by drivers/devices used in enterprise server 
> environment will be beneficial, not just for devices in which multiple ports 
> share a single PCI d/b/d/f("1 PCI d/b/d/f -> 2 ports"),  also for  multiport 
> devices with   "1 PCI d/b/d/f -> 1 Port" mapping.  The following scenarios 
> demonstrate the requirement/usefulness -
>
> 1.  As the dev_id would indicate the physical port number used by a netdevice 
> and will be available to user space via sysfs, tools such as NetworkManager 
> could use the information to implement intelligent/smarter bonding of 
> netdevices. For example, when bonding netdevices coming from NIC partitions 
> (or SR-IOV VFs) which use the same physical port, in fault tolerance mode for 
> example, NM could inform the user that the netdevices  being enslaved map 
> to/use the same physical port and  bonding them may not have desired effect. 
> Dev_id would provide such information in a generic way.
>
> 2. biosdevname could possibly use 'dev_id' to determine the <port> part of 
> p<slot>p<port> eliminating the need to determine/enumerate port number as 
> pointed out here.

Using dev_id in the kernel for static and predictable per-device
properties is fine, sure.

Using dev_id with per-driver-global internal counters, or anything
else that depends on any sort of probing or loading order is not; the
range of dev_id must be local to every "instance" than can be
separated and which the driver handles.

Otherwise, I would not be surprised if the "creativity" of people
would introduce new artificial and unpredictable enumerations in the
kernel with that facility. :)

Kay
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Reply via email to