From mboxrd@z Thu Jan 1 00:00:00 1970 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) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=n3TLiIE8cLurkLoJFVw2vmpn0wRbWJBTdKg817dnzok=; b=JCnpoxMAxNQNERiEW5GN43qPTFWYrz6RjoRuHCbsyN1AyRukCoiXHN4Jv4F2HR6y9X gwQ8Bwxxkf2fpKx/px42QUWk1sKi90ccHUfVvN6WqSK/v51UxAfITpCaQUYeRvA7YwsN 1szQKB3fPNIIVGhldi9wcZOkD/tK1BNOyDeqe7w1r9a3C5tx2T8Tclz1z1oo4nHEc9Rw kHebAhvVOHf5pXGSrX2OG7cAUAOV5O1eRhEcOF8Uc4kkbW6/Q4NSUst1xqmat72/8elf tlzU++BCZG40Mw0OEtEnyPeB/teAoH4Nk2D/L7vST8RYqJUqrqA3CkBspeFfe+NCMjIt yOOw== X-Gm-Message-State: ALoCoQm9+AdA6A50Aoytgyk7WqmJ8iWyiGsG/wHqiIMJmsJlOLNIYUvyLIVRfegOaxKfeOeB1XNV X-Received: by 10.180.39.131 with SMTP id p3mr29778592wik.82.1434641672435; Thu, 18 Jun 2015 08:34:32 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id ju2sm13634795wid.12.2015.06.18.08.34.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2015 08:34:31 -0700 (PDT) From: Thomas Monjalon To: Marc Sune Date: Thu, 18 Jun 2015 17:33:29 +0200 Message-ID: <1486154.EA56dXD0Dn@xps13> Organization: 6WIND User-Agent: KMail/4.14.8 (Linux/4.0.4-2-ARCH; KDE/4.14.8; x86_64; ; ) In-Reply-To: <5582DE84.5040702@bisdn.de> References: <98CBD80474FA8B44BF855DF32C47DC358AF172@smartserver.smartshare.dk> <5582DE84.5040702@bisdn.de> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Cc: dev@dpdk.org, Morten =?ISO-8859-1?Q?Br=F8rup?= Subject: Re: [dpdk-dev] [PATCH v2 1/2] Added ETH_SPEED_CAP bitmap in rte_eth_dev_info 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: Thu, 18 Jun 2015 15:34:32 -0000 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.