From mboxrd@z Thu Jan 1 00:00:00 1970 From: Veaceslav Falico Subject: Re: [PATCH v1 net-next 1/2] bonding: Expand speed type bits of the AD Port Key Date: Wed, 12 Nov 2014 12:20:02 +0100 Message-ID: <20141112112002.GA27653@raspberrypi> References: <1415603801-21285-1-git-send-email-Jianhua.Xie@freescale.com> <1415603801-21285-2-git-send-email-Jianhua.Xie@freescale.com> <20141111.135305.1647707440180670390.davem@davemloft.net> <19882.1415735238@famine> <54632E25.3000205@freescale.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Jay Vosburgh , David Miller , netdev@vger.kernel.org, andy@greyhouse.net To: Jianhua Xie Return-path: Received: from mail-wg0-f42.google.com ([74.125.82.42]:61138 "EHLO mail-wg0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751806AbaKLLUI (ORCPT ); Wed, 12 Nov 2014 06:20:08 -0500 Received: by mail-wg0-f42.google.com with SMTP id k14so13806613wgh.1 for ; Wed, 12 Nov 2014 03:20:06 -0800 (PST) Content-Disposition: inline In-Reply-To: <54632E25.3000205@freescale.com> Sender: netdev-owner@vger.kernel.org List-ID: 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=3D32) 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 tr= ick. No need to invent something special, and it'll fit nicely with other en= ums from AD. > >Thanks & Best Regards, >Jianhua > >=E5=9C=A8 2014=E5=B9=B411=E6=9C=8812=E6=97=A5 03:47, Jay Vosburgh =E5=86= =99=E9=81=93: >>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 th= at >>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 o= f >>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 use= d >>to determine if a port is LACP-capable, and that functionality needs = to >>be preserved. >> >> -J >> >>--- >> -Jay Vosburgh, jay.vosburgh@canonical.com >