Date:	Thu, 25 Jul 2013 23:44:42 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Alexander Duyck <alexander.h.duyck@...el.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 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.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

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