From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro Subject: Re: [PATCH v5 3/4] ethdev: redesign link speed config API Date: Thu, 11 Feb 2016 16:27:25 +0100 Message-ID: <20160211152725.GF14424@autoinstall.dev.6wind.com> References: <1440807373-24770-1-git-send-email-marc.sune@bisdn.de> <1443993167-1150-1-git-send-email-marcdevel@gmail.com> <1443993167-1150-4-git-send-email-marcdevel@gmail.com> <20160202132035.3db9bc4b@samsung9> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" To: Marc Return-path: Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by dpdk.org (Postfix) with ESMTP id 4CF271DB1 for ; Thu, 11 Feb 2016 16:27:43 +0100 (CET) Received: by mail-wm0-f48.google.com with SMTP id c200so78413897wme.0 for ; Thu, 11 Feb 2016 07:27:43 -0800 (PST) Content-Disposition: inline In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, Feb 02, 2016 at 11:30:59PM +0100, Marc wrote: > On 2 February 2016 at 03:20, Stephen Hemminger > wrote: >=20 > > On Thu, 28 Jan 2016 17:33:20 +0000 > > Harish Patil wrote: > > > > > * Added utility MACROs ETH_SPEED_NUM_XXX with the numeric > > > values of all supported link speeds, in Mbps. > > > > I would prefer that there were no speed value macros. > > Linux used to have these, but people kept adding new hardware speeds > > and it soon gets out of date. > > >=20 > I see what you mean, but I am not sure I agree. Link speeds are general= ly a > reduced amount of items (~20). Though it is true it can eventually grow= , > but at small rate. Having numeric constants all over the source seems l= ess > readable and less maintainable (e.g. less "grepable"/"sedable") to me. >=20 >=20 > > > > If you are going to redo it, then just increase speed to 64 bit, and = allow > > any non-zero value. > > >=20 > Value is now 32 bits, which I think is enough for future rates in mbps. > Since these constants were there, and before doing something to have to > revert it, can someone else give his/her opinion on this? For non 64bit architecture it is better to keep it on 32 bit but, if this field is only used on control plane we can afford 64 bit field and avoid another ABI breakage (in a far future). Even if this 32 bit field seems large enough you can already find on Internet some reports of transmission of petabit/s [1], we can imagine a NIC which provide this possibility by aggregating a lot of optical links and DPDK only will see it as single one. > If there is consensus, I've no problem on removing it for v8 >=20 > Thanks > marc [1] http://optics.org/news/4/1/29 --=20 N=E9lio Laranjeiro 6WIND