From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by dpdk.org (Postfix) with ESMTP id 54B0C282 for ; Mon, 14 Sep 2015 12:52:08 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Sep 2015 12:52:03 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC358AF3B7@smartserver.smartshare.dk> In-Reply-To: <2046894.c3eJ0QZGuc@xps13> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dpdk-dev] [PATCH v4 0/2] ethdev: add port speed capability bitmap Thread-Index: AdDuaenKPL1cKfvuSVG3V6DLvx3lGQAajXuw References: <20150909131037.GA25122@autoinstall.dev.6wind.com> <2699193.9riTyGPe1z@xps13> <2046894.c3eJ0QZGuc@xps13> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Thomas Monjalon" , "Marc Sune" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v4 0/2] ethdev: add port speed capability bitmap X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 10:52:08 -0000 It is important to consider that a multipath link (bonding etc.) is not = a physical link, but a logical link (built on top of multiple physical = links). Regardless whether it is a Layer2 link aggregate (IEEE 802.1ad, = Ethernet bonding, EtherChannel, DSL pair bonding, etc.) or a Layer3 = multipath link (e.g. simultaneously using Wi-Fi and mobile networks). So = it doesn't make sense trying to impose physical link properties on a = purely logical link. Likewise, it doesn't make sense to impose logical = link properties on physical links. In other words: Don't consider = bonding or any other logical link types when designing the PHY API. I think there is consensus that 1/ (PHY capabilities) and 2/ (PHY = advertisements) should use the same definitions, specifically a bitmap = field. And when you disregard bonding, I don't see any reason to use = different definitions for 3/ (PHY negotiation result). This makes it one = unified API for all three purposes. Nelio suggested adding a support function to convert the bitmap field to = a speed value as an integer. I strongly support this, because you cannot = expect the bitmap to be ordered by speed. This support function will be = able to determine which speed is higher when exotic speeds are added to = the bitmap. Please extend this conversion function to give three output = parameters: speed, full/half duplex, auto negotiation/non-auto = negotiation, or add two separate functions to get the duplex and = auto-negotiation. I haven't read the suggested code, but there should be some means in 2/ = (advertisements) to disable auto negotiation, e.g. a single bit in the = bitmap to indicate if the speed/duplex-indicating bits in the bitmap = means forced speed/duplex (in which case only a single speed/duplex-bit = should be set) or auto negotiation advertised speed/duplex (in which = case multiple speed/duplex-bits can be set). And some means in 3/ = (result) and maybe 2/ (advertisements) to select and/or indicate = physical interface in dual-personality ports (e.g. ports where the PHY = has both an SFP and a RJ45 connector, but only one of the two can be = used at any time). Med venlig hilsen / kind regards - Morten Br=F8rup -----Original Message----- From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]=20 Sent: 13. september 2015 23:19 To: Marc Sune Cc: N=E9lio Laranjeiro; dev@dpdk.org; Olga Shern; Adrien Mazarguil; = Morten Br=F8rup Subject: Re: [dpdk-dev] [PATCH v4 0/2] ethdev: add port speed capability = bitmap 2015-09-13 21:14, Marc Sune: > 2015-09-09 15:33 GMT+02:00 Thomas Monjalon = : > > 2015-09-09 15:10, N=E9lio Laranjeiro: > > > I think V2 is better, maybe you can add a function to convert a=20 > > > single bitmap value to the equivalent integer and get rid of=20 > > > ETH_SPEED_XXX > > macros. > > > > > > Thomas what is your opinion? > > > > Your proposal looks good Nelio. >=20 > I am confused, specially since you were the one advocating for having=20 > a unified set of constants for speeds (discussion in v2). Yes, my first thought was advocating an unification between capabilities = and negotiated link properties. After I was convinced by Nelio's arguments: bitmap is good for = capabilities (especially to describe every capabilities in one field) = but integer is better for negotiated speed (especially for aggregated = links). Converting bitmap speed into integer should be easy to implement in a = function. > In any case, as I see it, if we want to address the comments of M. = Brorup: >=20 > http://comments.gmane.org/gmane.comp.networking.dpdk.devel/19664 >=20 > we need bitmaps for rte_eth_conf link_speed to set the advertised = speeds. Yes I forgot this interesting comment. It is saying we need 1/ capabilities 2/ advertised modes (for auto-negotiation or fixed config) 3/ negotiated mode Previously we were focused only on 1/ and 3/. 2/ was only limited to a mode configured without negotiation and was = using the same field as 3/. Maybe we should really have 3 different fields. 1/ and 2/ would use a = bitmap. > Let me know if you really want to come back to v2 or not. It needs more discussion. What do you think of the above proposal? What is the opinion of Nelio? Morten?