From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by dpdk.org (Postfix) with ESMTP id 486B45A87 for ; Fri, 29 May 2015 20:41:02 +0200 (CEST) Received: by wivl4 with SMTP id l4so25729393wiv.1 for ; Fri, 29 May 2015 11:41:02 -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=bQ90MC+XSc12ylHlYkiELIYJGWOmPLx4/dL4xPK5Wqk=; b=Gzd094NtYFX4HWAqUJh1t6YqPcGlZaJ6BLuvns8qeMpbhPK1fl2OemA66xPyp6r4lr +h0S9qPqFXGeKS5fzNgg28YS6EvRcr8UgTa+uAKIVdfZsD3tr5jxVLxqpnHPSxKGTEis rBCpFeo8iA3B3UtI6oL4yqo37WYFzn9lNgHcPQJe/06HQtFTO3NjU2z7z2I/G677Npiw bWNEEhst5rTHD4YEIJfJvGvbQoPeW5vfTxd0NX9AHYtGoD0/O5M22KORp7AIw6rWR5BI HGTfgNOCuKvi3BbNQIFwvXO9RwKPnpw6C8mTnLrqzd6iAbJyHhLtP2VmNkO8apZTIp5+ okpQ== X-Gm-Message-State: ALoCoQkYsRxXjjOjd6BSYlCyZfDDqErJcDAB8Xvw7jIAPaeJlBuUnqvAxS/s9KHVimsVLdL6mjmZ X-Received: by 10.194.134.9 with SMTP id pg9mr18105482wjb.5.1432924862119; Fri, 29 May 2015 11:41:02 -0700 (PDT) Received: from xps13.localnet (166.16.90.92.rev.sfr.net. [92.90.16.166]) by mx.google.com with ESMTPSA id a18sm9489251wja.46.2015.05.29.11.41.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 May 2015 11:41:01 -0700 (PDT) From: Thomas Monjalon To: Marc Sune Date: Fri, 29 May 2015 20:23:20 +0200 Message-ID: <5394923.Bu4Z07Mj4A@xps13> Organization: 6WIND User-Agent: KMail/4.14.7 (Linux/4.0.1-1-ARCH; KDE/4.14.7; x86_64; ; ) In-Reply-To: <55658B30.6030105@bisdn.de> References: <1431387946-29950-1-git-send-email-marc.sune@bisdn.de> <2412503.21Wb9XeS85@xps13> <55658B30.6030105@bisdn.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: Fri, 29 May 2015 18:41:02 -0000 2015-05-27 11:15, Marc Sune: > On 27/05/15 06:02, Thomas Monjalon wrote: > > 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. No sorry, I missed how low your first values were. > >> +#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? > > 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. You're right. > 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. No, if we want to show this variable is a bitmap, the variable name may be changed, not the type. It would bring clarity when reading code using this variable but I think it's not really needed.