From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx.bisdn.de (mx.bisdn.de [185.27.182.31]) by dpdk.org (Postfix) with ESMTP id E30DBC3E6 for ; Thu, 18 Jun 2015 17:06:45 +0200 (CEST) Received: from [172.16.250.156] (unknown [172.16.250.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx.bisdn.de (Postfix) with ESMTPSA id 90692A3049; Thu, 18 Jun 2015 17:06:45 +0200 (CEST) Message-ID: <5582DE84.5040702@bisdn.de> Date: Thu, 18 Jun 2015 17:06:44 +0200 From: Marc Sune User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: dev@dpdk.org, Thomas Monjalon References: <98CBD80474FA8B44BF855DF32C47DC358AF172@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC358AF172@smartserver.smartshare.dk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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:06:46 -0000 On 18/06/15 16:43, Morten Brørup wrote: > Regarding the PHY speed ABI: > > > > 1. The Ethernet PHY ABI for speed, duplex, etc. should be common throughout the entire DPDK. It might be confusing if some structures/functions use a bitmask to indicate PHY speed/duplex/personality/etc. and other structures/functions use a combination of an unsigned integer, duplex flag, personality enumeration etc. (By personality enumeration, I am referring to PHYs with multiple electrical interfaces. E.g. a dual personality PHY might have both an RJ45 copper interface and an SFP module interface, whereof only one can be active at any time.) Thomas was sending a similar comment and I agreed to do a unified speed bitmap for both capabilities and link negotiation/link info (v3, waiting for 2.2 merge window): http://dpdk.org/ml/archives/dev/2015-June/019207.html > > > > 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 configured to announce 10 Mbit/s half duplex and 100 Mbit/s full duplex capabilities to its link partner. (Of course, more useful combinations are normally announced, but the purpose of the example is to show that any combination is possible.) > > > > The ABI for auto-negotiation should include options to select the list of capabilities to announce to the link partner. The Linux PHY ABI only 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. I see what you mean, and you are probably right. In any case this is for a separate patch, if we think it is a necessary feature to implement. Nevertheless, this makes me rethink about the proposal from Thomas about unifying _100_HD/_100_FD to 100M, because you will need this granularity, eventually. @Thomas: opinions? Thanks Marc p.s. Please configure your email client to reply using "In-Reply-To:" to allow clients and ML archives to use threading. > > > PS: While working for Vitesse Semiconductors (an Ethernet chip company) a long time ago, I actually wrote the API for their line of Ethernet PHYs. So I have hands on experience in this area. > > > > > > Med venlig hilsen / kind regards > > > > Morten Brørup > > CTO > > > > > > > > SmartShare Systems A/S > > Tonsbakken 16-18 > > DK-2740 Skovlunde > > Denmark > > > > Office +45 70 20 00 93 > > Direct +45 89 93 50 22 > > Mobile +45 25 40 82 12 > > > > mb@smartsharesystems.com > > www.smartsharesystems.com > > >