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

On Wed, Nov 12, 2014 at 05:53:41PM +0800, Jianhua Xie wrote:
>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?

As it's visible to bonding only, I guess a simple enum should do the trick.
No need to invent something special, and it'll fit nicely with other enums
from AD.

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