Date:	Fri, 5 Dec 2014 09:54:33 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	"'Eric W. Biederman'" <ebiederm@...ssion.com>,
	Jiri Pirko <jiri@...nulli.us>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"nhorman@...driver.com" <nhorman@...driver.com>,
	"andy@...yhouse.net" <andy@...yhouse.net>,
	"tgraf@...g.ch" <tgraf@...g.ch>,
	"dborkman@...hat.com" <dborkman@...hat.com>,
	"ogerlitz@...lanox.com" <ogerlitz@...lanox.com>,
	"jesse@...ira.com" <jesse@...ira.com>,
	"pshelar@...ira.com" <pshelar@...ira.com>,
	"azhou@...ira.com" <azhou@...ira.com>,
	"ben@...adent.org.uk" <ben@...adent.org.uk>,
	"stephen@...workplumber.org" <stephen@...workplumber.org>,
	"jeffrey.t.kirsher@...el.com" <jeffrey.t.kirsher@...el.com>,
	"vyasevic@...hat.com" <vyasevic@...hat.com>,
	"xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>,
	"john.r.fastabend@...el.com" <john.r.fastabend@...el.com>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"jhs@...atatu.com" <jhs@...atatu.com>,
	"sfeldma@...il.com" <sfeldma@...il.com>,
	"f.fainelli@...il.com" <f.fainelli@...il.com>,
	"roopa@...ulusnetworks.com" <roopa@...ulusnetworks.com>,
	"linville@...driver.com" <linville@...driver.com>,
	"jasowang@...hat.com" <jasowang@...hat.com>,
	"nicolas.dichtel@...nd.com" <nicolas.dichtel@...nd.com>,
	"ryazanov.s.a@...il.com" <ryazanov.s.a@...il.com>,
	"buytenh@...tstofly.org" <buytenh@...tstofly.org>,
	"aviadr@...lanox.com" <aviadr@...lanox.com>,
	"nbd@...nwrt.org" <nbd@...nwrt.org>,
	"alexei.starovoitov@...il.com" <alexei.starovoitov@...il.com>,
	"Neil.Jerram@...aswitch.com" <Neil.Jerram@...aswitch.com>,
	"ronye@...lanox.com" <ronye@...lanox.com>,
	"simon.horman@...ronome.com" <simon.horman@...ronome.com>,
	"alexander.h.duyck@...hat.com" <alexander.h.duyck@...hat.com>,
	"john.ronciak@...el.com" <john.ronciak@...el.com>,
	"mleitner@...hat.com" <mleitner@...hat.com>,
	"shrijeet@...il.com" <shrijeet@...il.com>,
	"gospo@...ulusnetworks.com" <gospo@...ulusnetworks.com>,
	"bcrl@...ck.org" <bcrl@...ck.org>,
	"hemal@...adcom.com" <hemal@...adcom.com>
Subject: RE: [patch iproute2 1/6] iproute2: ipa: show switch id

From: Eric W. Biederman
> Jiri Pirko <jiri@...nulli.us> writes:
> 
> > Thu, Dec 04, 2014 at 09:06:14PM CET, ebiederm@...ssion.com wrote:
> >>ebiederm@...ssion.com (Eric W. Biederman) writes:
> >>
> >>> Jiri Pirko <jiri@...nulli.us> writes:
> >>>
> >>>>>So this id needs to be globally unique?
> >>>>
> >>>> No. It is enough to be unique within a single system. It serves for no
> >>>> more than to find out 2 ids are same or not, no other info value.
> >>>>
> >>>> So when the drivers uses sane ids (like mac for example, or in case of
> >>>> rocker an id which is passed by qemu command line), the chances of
> >>>> collision are very very close to none (never say never).
> >>
> >>Thinking about what you said a little more.
> >>
> >>Two different sources of persistent numbers picking numbers by
> >>completely different algorithms can give you no assurance that you don't
> >>produce conflicts.
> >>
> >>The switch id as desisgned can not work.
> >>
> >>There are expected to be between 2**36 to 2**40 devices in this world.
> >>Your first switch id is a 64it number.  At the very best by the birthday
> >>pardox predicts there will be a conflict ever 2**32 devices or between
> >>2**4 and 2**8 devices in the world with conflicts.  If the ids are not
> >>randomly distributed (which they won't be) things could easily be much
> >>much worse.
> >>
> >>That is just good enough the code could get out there and run for years
> >>before you have the nightmare of having to fix all of userspace.   That
> >>is a nightmare no one needs.
> >>
> >>So please remove this broken code, and this broken concept from the
> >>kernel and go back to the drawing board.
> >
> > In that case the phys port id is broken in the same way. Let's rather
> > think about how to avoid conflicts for both. Given the fact the
> > conflicts should be avoided only on a single baremetal, that should be
> > doable (for (bad) example using driver name mixed with driver created
> > id).
> 
> No.  phys_port_id is not broken in the same way, and phys_port_id does
> not have the same set of properties.
> 
> phys_port_id's in practice all have an IEEE prefix that identifies the
> manufacturer and a manufacture assigned serial number.  Aka a mac
> address or a EUID-64.  What the mlx4 ethernet driver is doing retunring
> a 64bit EUID-64 I don't know.  If there are problems in the worst
> case issues with phys_port_id are fixable by simple driver tweaks,
> because fundamentally we are working with globally uniuqe identifiers.
> Well globally unique baring manufacturing bugs in eeproms.

Manufacturers have to generate unique MAC addresses - otherwise people complain.
But can't be assumed to put different 'serial numbers' in other devices.
If you look at USB memory sticks you are likely to find that the serial
number in the (equivalent of the) ATA identify response isn't unique.
So I doubt you can use the value to distinguish between devices.

You also get the situation where ethernet MAC addresses only have to be
unique within a collision domain. Many old sun systems used a single MAC
address - valid because they assumed/required that multiple interfaces
be connected to different networks.
So even MAC addresses aren't per-interface.

	David



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