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 E8B2D9A9E for ; Thu, 11 Jun 2015 16:35:27 +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 C4F35A3B3E; Thu, 11 Jun 2015 16:35:26 +0200 (CEST) Message-ID: <55799CAD.7000105@bisdn.de> Date: Thu, 11 Jun 2015 16:35:25 +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: Thomas Monjalon References: <1431387946-29950-1-git-send-email-marc.sune@bisdn.de> <5394923.Bu4Z07Mj4A@xps13> <55755754.4070508@bisdn.de> <5698652.MiVIRsgeEt@xps13> In-Reply-To: <5698652.MiVIRsgeEt@xps13> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org 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, 11 Jun 2015 14:35:28 -0000 On 11/06/15 11:08, Thomas Monjalon wrote: > 2015-06-08 10:50, Marc Sune: >> On 29/05/15 20:23, Thomas Monjalon wrote: >>> 2015-05-27 11:15, Marc Sune: >>>> On 27/05/15 06:02, Thomas Monjalon wrote: >>>>>> +#define ETH_SPEED_CAP_10M_HD (1 << 0) /*< 10 Mbps half-duplex> */ >>>>>> +#define ETH_SPEED_CAP_10M_FD (1 << 1) /*< 10 Mbps full-duplex> */ >>>>>> +#define ETH_SPEED_CAP_100M_HD (1 << 2) /*< 100 Mbps half-duplex> */ >>>>>> +#define ETH_SPEED_CAP_100M_FD (1 << 3) /*< 100 Mbps full-duplex> */ >>>>>> +#define ETH_SPEED_CAP_1G (1 << 4) /*< 1 Gbps > */ >>>>>> +#define ETH_SPEED_CAP_2_5G (1 << 5) /*< 2.5 Gbps > */ >>>>>> +#define ETH_SPEED_CAP_5G (1 << 6) /*< 5 Gbps > */ >>>>>> +#define ETH_SPEED_CAP_10G (1 << 7) /*< 10 Mbps > */ >>>>>> +#define ETH_SPEED_CAP_20G (1 << 8) /*< 20 Gbps > */ >>>>>> +#define ETH_SPEED_CAP_25G (1 << 9) /*< 25 Gbps > */ >>>>>> +#define ETH_SPEED_CAP_40G (1 << 10) /*< 40 Gbps > */ >>>>>> +#define ETH_SPEED_CAP_50G (1 << 11) /*< 50 Gbps > */ >>>>>> +#define ETH_SPEED_CAP_56G (1 << 12) /*< 56 Gbps > */ >>>>>> +#define ETH_SPEED_CAP_100G (1 << 13) /*< 100 Gbps > */ >>>>> We should note that rte_eth_link is using ETH_LINK_SPEED_* constants >>>>> which are not some bitmaps so we have to create these new constants. >>>> Yes, I can add that to the patch description (1/2). >>>> >>>>> Furthermore, rte_eth_link.link_speed is an uint16_t so it is limited >>>>> to 40G. Should we use some constant bitmaps here also? >>>> I also thought about converting link_speed into a bitmap to unify the >>>> constants before starting the patch (there is redundancy), but I wanted >>>> to be minimally invasive; changing link to a bitmap can break existing apps. >>>> >>>> I can also merge them if we think is a better idea. >>> Maybe. Someone against this idea? >> Me. I tried implementing this unified speed constantss, but the problem >> is that for the capabilities full-duplex/half-duplex speeds are unrolled >> (e.g. 100M_HD/100_FD). There is no generic 100M to set a specific speed, > Or we can define ETH_SPEED_CAP_100M and ETH_SPEED_CAP_100M_FD. > Is it possible to have a NIC doing 100M_FD but not 100M_HD? Did not check in detail, but I guess this is mostly legacy NICs, not supported by DPDK anyway, and that is safe to assume 10M/100M meaning supports both HD/FD. > >> so if you want a fiex speed and duplex auto-negociation witht the >> current set of constants, it would look weird; e.g. >> link_speed=ETH_SPEED_100M_HD and then set >> link_duplex=ETH_LINK_AUTONEG_DUPLEX): >> >> 232 struct rte_eth_link { >> 233 uint16_t link_speed; /**< ETH_LINK_SPEED_[10, 100, >> 1000, 10000] */ >> 234 uint16_t link_duplex; /**< ETH_LINK_[HALF_DUPLEX, >> FULL_DUPLEX] */ >> 235 uint8_t link_status : 1; /**< 1 -> link up, 0 -> link >> down */ >> 236 }__attribute__((aligned(8))); /**< aligned for atomic64 >> read/write */ >> >> There is another minor point, which is when setting the speed in >> rte_eth_conf: >> >> 840 struct rte_eth_conf { >> 841 uint16_t link_speed; >> 842 /**< ETH_LINK_SPEED_10[0|00|000], or 0 for autonegotation */ >> >> 0 is used for speed auto-negociation, but 0 is also used in the >> capabilities bitmap to indicate no PHY_MEDIA (virtual interface). I >> would have to define something like: >> >> 906 #define ETH_SPEED_NOT_PHY (0) /*< No phy media > */ >> 907 #define ETH_SPEED_AUTONEG (0) /*< Autonegociate speed > */ > Or something like SPEED_UNDEFINED Ok. I will prepare the patch and circulate a v3. After briefly chatting offline with Thomas, it seems I was not clearly stating in my original v1 that this patch is targeting DPDK v2.2, due to ABI(and API) issues. It is, and so I will hold v3 until 2.2 window starts, to make it more clear. thanks Marc > >> And use (only) NOT_PHY for a capabilities and _AUTONEG for rte_eth_conf. >> >> The options I see: >> >> a) add to the the list of the current speeds generic 10M/100M/1G speeds >> without HD/FD, and just use these speeds in rte_eth_conf. >> b) leave them separated. >> >> I would vote for b), since the a) is not completely clean. >> Opinions&other alternatives welcome. >> >> Marc