Date:	Mon, 08 Dec 2014 15:56:06 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	David Laight <David.Laight@...LAB.COM>
Cc:	Jiri Pirko <jiri@...nulli.us>,
	"netdev\@vger.kernel.org" <netdev@...r.kernel.org>,
	"davem\@davemloft.net" <davem@...emloft.net>,
	"nhorman\@tuxdriver.com" <nhorman@...driver.com>,
	"andy\@greyhouse.net" <andy@...yhouse.net>,
	"tgraf\@suug.ch" <tgraf@...g.ch>,
	"dborkman\@redhat.com" <dborkman@...hat.com>,
	"ogerlitz\@mellanox.com" <ogerlitz@...lanox.com>,
	"jesse\@nicira.com" <jesse@...ira.com>,
	"pshelar\@nicira.com" <pshelar@...ira.com>,
	"azhou\@nicira.com" <azhou@...ira.com>,
	"ben\@decadent.org.uk" <ben@...adent.org.uk>,
	"stephen\@networkplumber.org" <stephen@...workplumber.org>,
	"jeffrey.t.kirsher\@intel.com" <jeffrey.t.kirsher@...el.com>,
	"vyasevic\@redhat.com" <vyasevic@...hat.com>,
	"xiyou.wangcong\@gmail.com" <xiyou.wangcong@...il.com>,
	"john.r.fastabend\@intel.com" <john.r.fastabend@...el.com>,
	"edumazet\@google.com" <edumazet@...gle.com>,
	"jhs\@mojatatu.com" <jhs@...atatu.com>,
	"sfeldma\@gmail.com" <sfeldma@...il.com>,
	"f.fainelli\@gmail.com" <f.fainelli@...il.com>,
	"roopa\@cumulusnetworks.com" <roopa@...ulusnetworks.com>,
	"linville\@tuxdriver.com" <linville@...driver.com>,
	"jasowang\@redhat.com" <jasowang@...hat.com>,
	"nicolas.dichtel\@6wind.com" <nicolas.dichtel@...nd.com>,
	"ryazanov.s.a\@gmail.com" <ryazanov.s.a@...il.com>,
	"buytenh\@wantstofly.org" <buytenh@...tstofly.org>,
	"aviadr\@mellanox.com" <aviadr@...lanox.com>,
	"nbd\@openwrt.org" <nbd@...nwrt.org>,
	"alexei.starovoitov\@gmail.com" <alexei.starovoitov@...il.com>,
	"Neil.Jerram\@metaswitch.com" <Neil.Jerram@...aswitch.com>,
	"ronye\@mellanox.com" <ronye@...lanox.com>,
	"simon.horman\@netronome.com" <simon.horman@...ronome.com>,
	"alexander.h.duyck\@redhat.com" <alexander.h.duyck@...hat.com>,
	"john.ronciak\@intel.com" <john.ronciak@...el.com>,
	"mleitner\@redhat.com" <mleitner@...hat.com>,
	"shrijeet\@gmail.com" <shrijeet@...il.com>,
	"gospo\@cumulusnetworks.com" <gospo@...ulusnetworks.com>,
	"bcrl\@kvack.org" <bcrl@...ck.org>,
	"hemal\@broadcom.com" <hemal@...adcom.com>
Subject: Re: [patch iproute2 1/6] iproute2: ipa: show switch id

David Laight <David.Laight@...LAB.COM> writes:

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

When I said serial number I was talking about MAC addresses.

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

The old sun system issue does not apply to switches and switch like
devices.

There are common layer two protocls (Spanning Tree? LACP?) that require
each switch port to have a unique mac address.  So people will complain
and software will break if there is not a mac address per port.  So for
switches and things that strongly resemble switches assuming a unique
mac address per port is a reasonable assumption.

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