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 A4CB6DE6 for ; Wed, 27 May 2015 11:15:30 +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 53808A23F3; Wed, 27 May 2015 11:15:30 +0200 (CEST) Message-ID: <55658B30.6030105@bisdn.de> Date: Wed, 27 May 2015 11:15:28 +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> <1432669843-15672-1-git-send-email-marc.sune@bisdn.de> <1432669843-15672-2-git-send-email-marc.sune@bisdn.de> <2412503.21Wb9XeS85@xps13> In-Reply-To: <2412503.21Wb9XeS85@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: Wed, 27 May 2015 09:15:31 -0000 On 27/05/15 06:02, Thomas Monjalon wrote: > Hi Marc, > > 2015-05-26 21:50, Marc Sune: >> Added constants and bitmap to struct rte_eth_dev_info to be used by PMDs. >> >> Signed-off-by: Marc Sune > [...] >> +/** >> + * Device supported speeds >> + */ >> +#define ETH_SPEED_CAP_NOT_PHY (0) /*< No phy media > */ > Why not starting with lower values? Some new drivers may be interested > by lower speed. Ok, but which values? 1Mbps FD/HD? Even lower than that? If you have some NIC(s) in mind with lower values, please point me to that and I will collect&add the missing speeds. > >> +#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. > What about removing _CAP suffix from your constants? I added the suffix to make clearer the distinction with link speeds. I can remove it if we merge both or if we consider it is not necessary. > > [...] >> + uint32_t speed_capa; /**< Supported speeds bitmap (ETH_SPEED_CAP_). */ > If the constants are ETH_SPEED_CAP, why not wording this variable speed_cap? I followed the convention of the existing rx/tx offload capability bitmaps: marc@dev:~/git/bisdn/msune/xdpd/libs/dpdk/lib$ grep _capa\; * -R librte_ether/rte_ethdev.h: uint32_t rx_offload_capa; /**< Device RX offload capabilities. */ librte_ether/rte_ethdev.h: uint32_t tx_offload_capa; /**< Device TX offload capabilities. */ I am fine with speed_cap or speed_caps, but I think we should have some consistency on how we name bitmaps. If we would want to make the bitmaps more explicit, we could define some helper typedefs in EAL: typedef uint16_t bitmap16_t; typedef uint32_t bitmap32_t; typedef uint64_t bitmap64_t; and replace the bitmaps of the structs, again specially the ones used by the users. marc >