lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 12 Nov 2014 12:20:02 +0100
From:	Veaceslav Falico <>
To:	Jianhua Xie <>
Cc:	Jay Vosburgh <>,
	David Miller <>,,
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,
>在 2014年11月12日 03:47, Jay Vosburgh 写道:
>>David Miller <> wrote:
>>>From: Xie Jianhua <>
>>>Date: Mon, 10 Nov 2014 15:16:40 +0800
>>>>From: Jianhua Xie <>
>>>>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
>>>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,
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists