From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v2 1/2] Added ETH_SPEED_CAP bitmap in rte_eth_dev_info Date: Thu, 18 Jun 2015 17:33:29 +0200 Message-ID: <1486154.EA56dXD0Dn@xps13> References: <98CBD80474FA8B44BF855DF32C47DC358AF172@smartserver.smartshare.dk> <5582DE84.5040702@bisdn.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: dev@dpdk.org, Morten =?ISO-8859-1?Q?Br=F8rup?= To: Marc Sune Return-path: Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id 8DB3B255 for ; Thu, 18 Jun 2015 17:34:32 +0200 (CEST) Received: by wgzl5 with SMTP id l5so67205104wgz.3 for ; Thu, 18 Jun 2015 08:34:32 -0700 (PDT) In-Reply-To: <5582DE84.5040702@bisdn.de> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2015-06-18 17:06, Marc Sune: > On 18/06/15 16:43, Morten Br=F8rup wrote: > > Regarding the PHY speed ABI: > > > > 1. The Ethernet PHY ABI for speed, duplex, etc. should be common th= roughout the entire DPDK. It might be confusing if some structures/func= tions use a bitmask to indicate PHY speed/duplex/personality/etc. and o= ther structures/functions use a combination of an unsigned integer, dup= lex flag, personality enumeration etc. (By personality enumeration, I a= m referring to PHYs with multiple electrical interfaces. E.g. a dual pe= rsonality PHY might have both an RJ45 copper interface and an SFP modul= e interface, whereof only one can be active at any time.) >=20 > Thomas was sending a similar comment and I agreed to do a unified spe= ed=20 > bitmap for both capabilities and link negotiation/link info (v3, wait= ing=20 > for 2.2 merge window): >=20 > http://dpdk.org/ml/archives/dev/2015-June/019207.html It would be better to try merging it in 2.1 while keeping an ABI backwa= rd compatibility. > > 2. The auto-negotiation standard allows the PHY to announce (to its= link > > partner) any subset of its capabilities to its link partner. E.g. a= > > standard 10/100/100 Ethernet PHY (which can handle both 10 and 100 = Mbit/s > > in both half and full duplex and 1 Gbit/s full duplex) can be confi= gured > > to announce 10 Mbit/s half duplex and 100 Mbit/s full duplex capabi= lities > > to its link partner. (Of course, more useful combinations are norma= lly > > announced, but the purpose of the example is to show that any combi= nation > > is possible.) > > > > The ABI for auto-negotiation should include options to select the l= ist of > > capabilities to announce to the link partner. The Linux PHY ABI onl= y > > allows forcing a selected speed and duplex (thereby disabling > > auto-negotiation) or enabling auto-negotiation (thereby announcing = all > > possible speeds and duplex combinations the PHY is capable of). Don= 't make > > the same mistake in DPDK. >=20 > I see what you mean, and you are probably right. In any case this is = for=20 > a separate patch, if we think it is a necessary feature to implement.= >=20 > Nevertheless, this makes me rethink about the proposal from Thomas ab= out=20 > unifying _100_HD/_100_FD to 100M, because you will need this=20 > granularity, eventually. @Thomas: opinions? I think Morten's advice is good. Are we going to have half duplex links for PHY faster than 100M? If not, we can manage them with a hackish define 100M_HD and a 100M which implicitly means full duplex.