Message-ID: <51F1AD2E.5000707@intel.com>
Date:	Thu, 25 Jul 2013 15:56:46 -0700
From:	Alexander Duyck <alexander.h.duyck@...el.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
CC:	John Fastabend <john.fastabend@...il.com>,
	Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org,
	davem@...emloft.net, stephen@...workplumber.org,
	Narendra_K@...l.com, john.r.fastabend@...el.com,
	or.gerlitz@...il.com, jeffrey.t.kirsher@...el.com,
	jesse.brandeburg@...el.com, bruce.w.allan@...el.com,
	carolyn.wyborny@...el.com, donald.c.skidmore@...el.com,
	gregory.v.rose@...el.com, peter.p.waskiewicz.jr@...el.com,
	john.ronciak@...el.com, tushar.n.dave@...el.com,
	matthew.vick@...el.com, mitch.a.williams@...el.com,
	vyasevic@...hat.com, amwang@...hat.com, johannes@...solutions.net
Subject: Re: [patch net-next v4 4/4] igb/igbvf: implement ndo_get_phys_port_id

On 07/25/2013 03:44 PM, Ben Hutchings wrote:
> On Thu, 2013-07-25 at 15:27 -0700, Alexander Duyck wrote:
>> On 07/25/2013 12:58 PM, John Fastabend wrote:
>>> On 07/25/2013 12:15 PM, Ben Hutchings wrote:
>>>> On Thu, 2013-07-25 at 12:03 -0700, Alexander Duyck wrote:
> [...]
>>>>> Well like you mentioned, you could just pull this out out of
>>>>> netdev->perm_addr.  You don't need to have anything driver specific as
>>>>> long as that is the field you are using generic netdev or pci_dev
>>>>> attributes to do the identification.
>>>> For a PF driver that never shares the port with another PF, yes.  There
>>>> are a handful of those drivers so it might be worth sharing an
>>>> implementation that uses perm_addr, but it's so trivial...
>>>>
>>>>> All you need is something that
>>>>> uniquely identifies the device in the system correct?
>>>> The spec is that it is universally unique.  I don't know who's going to
>>>> need that property but I think it's achievable since each physical port
>>>> normally has at least one globally unique MAC address assigned at
>>>> manufacturing time.
>>>>
>>>>> For that matter
>>>>> it seems like you could probably just pull the domain, bus, device, and
>>>>> function number out of the PCI device and that would probably work as
>>>>> well as long as you cannot somehow have PFs running inside of guests.
>>>> Some NICs have multiple PFs for the same port, and those could be
>>>> assigned to guest VMs.
>>>>
>>>> All VF drivers would need some way to get the port ID, and that can't be
>>>> done generically from inside a guest VM.
>>>>
>>>> Ben.
>>>>
>>> I doubt you'll be able to think up a way to do this generically as Ben
>>> points out. But also no reason for the complicated hash just use the
>>> perm address of the PF and if you have multiple PFs elect one of the
>>> n perm address to be the stand-in for the unique one.
>>>
>>> .John
>>>
>> I think there may have been some miscommunication.  I wasn't talking
>> about the VF drivers having a generic means of getting the ID.  I would
>> just want all of the drivers to be using a similar approach for
>> generating the port ID so that we reduce the risk of any kind of port ID
>> collision.  We need to make sure we are all stuffing the 6 bytes of
>> perm_addr into the 4 byte port ID using the same approach.
> But we started with an up-to-32-byte port ID; why do you say 4 bytes?
>
> Ben.

Sorry I was looking at the driver specific implementation that was only
populating a u32.

Thanks,

Alex
--
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