Date:	Wed, 12 Nov 2014 17:53:41 +0800
From:	Jianhua Xie <jianhua.xie@...escale.com>
To:	Jay Vosburgh <jay.vosburgh@...onical.com>,
	David Miller <davem@...emloft.net>
CC:	<netdev@...r.kernel.org>, <vfalico@...il.com>, <andy@...yhouse.net>
Subject: Re: [PATCH v1 net-next 1/2] bonding: Expand speed type bits of the
 AD Port Key

Thanks you two for the valuable comments.

If my understanding is right,  it is encouraged to use a counter
rather than a bitmask for the speed field, right?

if yes, how many bits are better to use for current speed and
future speed (like 100Gbps/400Gbps and etc.)?  I am not sure
that 5 bits are enough (2**5=32) or not. And I am clear to keep
"the duplex bit in the key " in my mind.

if not, what's your recommendation please?

Thanks & Best Regards,
Jianhua

在 2014年11月12日 03:47, Jay Vosburgh 写道:
> David Miller <davem@...emloft.net> wrote:
>
>> From: Xie Jianhua <Jianhua.Xie@...escale.com>
>> Date: Mon, 10 Nov 2014 15:16:40 +0800
>>
>>> From: Jianhua Xie <Jianhua.Xie@...escale.com>
>>>
>>> Port Key was determined as 16 bits according to the link speed,
>>> duplex and user key (which is yet not supported), in which key
>>> speed was 5 bits for 1Mbps/10Mbps/100Mbps/1Gbps/10Gbps as below:
>>> --------------------------------------------------------------
>>> Port key :|	User key	| Speed		|	Duplex|
>>> --------------------------------------------------------------
>>> 16			6		1		0
>>> This patch is expanding speed type from 5 bits to 9 bits for other
>>> speed 2.5Gbps/20Gbps/40Gbps/56Gbps and shrinking user key from 10
>>> bits to 6 bits.  New Port Key looks like below:
>>> --------------------------------------------------------------
>>> Port key :|	User key	| Speed		|	Duplex|
>>> --------------------------------------------------------------
>>> 16			10		1		0
>>>
>> Do we determine the layout of this value all ourselves?
> 	Yes, we do.  The precise format of the port key is not defined
> by the standard; IEEE 802.1AX 5.3.5, "Capability identification":
>
> "A given Key value is meaningful only in the context of the System that
> allocates it; there is no global significance to Key values."
>
> 	and
>
> "When a System assigns an operational Key value to a set of ports, it
> signifies that, in the absence of other constraints, the current
> operational state of the set of ports allows any subset of that set of
> ports (including the entire set) to be aggregated together from the
> perspective of the System making the assignment."
>
> 	So, basically, it's a magic cookie that indicates that all ports
> on a particular system with the same key value are suitable to be
> aggregated together.
>
>> If not, then is it exported to anything user-visible that we
>> might be breaking?
> 	The key values are not user-visible, and the "user" settable
> portion of the key has never been implemented.
>
>> If it is private, it makes no sense to use a bitmask for the speed.
>> We should instead change the field to be some numerically increasing
>> value.
>>
>> Otherwise we'll run out of bits again and keep having to adjust the
>> field layout more often than we really need to.
> 	Agreed.
>
> 	Also note that there are some internal dependencies within
> bonding on the format; in particular the duplex bit in the key is used
> to determine if a port is LACP-capable, and that functionality needs to
> be preserved.
>
> 	-J
>
> ---
> 	-Jay Vosburgh, jay.vosburgh@...onical.com

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