netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jay Vosburgh <jay.vosburgh@canonical.com>
To: David Miller <davem@davemloft.net>
Cc: Jianhua.Xie@freescale.com, netdev@vger.kernel.org,
	vfalico@gmail.com, andy@greyhouse.net
Subject: Re: [PATCH v1 net-next 1/2] bonding: Expand speed type bits of the AD Port Key
Date: Tue, 11 Nov 2014 11:47:18 -0800	[thread overview]
Message-ID: <19882.1415735238@famine> (raw)
In-Reply-To: <20141111.135305.1647707440180670390.davem@davemloft.net>

David Miller <davem@davemloft.net> wrote:

>From: Xie Jianhua <Jianhua.Xie@freescale.com>
>Date: Mon, 10 Nov 2014 15:16:40 +0800
>
>> From: Jianhua Xie <Jianhua.Xie@freescale.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
>> 
>> CC: Jay Vosburgh <j.vosburgh@gmail.com>
>> CC: Veaceslav Falico <vfalico@gmail.com>
>> CC: Andy Gospodarek <andy@greyhouse.net>
>> CC: David S. Miller <davem@davemloft.net>
>> 
>> Signed-off-by: Jianhua Xie <jianhua.xie@freescale.com>
>
>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@canonical.com

  reply	other threads:[~2014-11-11 19:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-10  7:16 [PATCH v1 net-next 0/2] bonding: Introduce 4 AD link speed Xie Jianhua
2014-11-10  7:16 ` [PATCH v1 net-next 1/2] bonding: Expand speed type bits of the AD Port Key Xie Jianhua
2014-11-11 18:53   ` David Miller
2014-11-11 19:47     ` Jay Vosburgh [this message]
2014-11-12  9:53       ` Jianhua Xie
2014-11-12 11:20         ` Veaceslav Falico
2014-11-16  8:45           ` Jianhua Xie
2014-11-12 17:43         ` David Miller
2014-11-10  7:16 ` [PATCH v1 net-next 2/2] bonding: Introduce 4 AD link speed to fix agg_bandwidth Xie Jianhua

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19882.1415735238@famine \
    --to=jay.vosburgh@canonical.com \
    --cc=Jianhua.Xie@freescale.com \
    --cc=andy@greyhouse.net \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=vfalico@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).