From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) by dpdk.org (Postfix) with ESMTP id 8B8792A5D for ; Fri, 12 Feb 2016 00:24:08 +0100 (CET) Received: by mail-wm0-f67.google.com with SMTP id c200so13309422wme.0 for ; Thu, 11 Feb 2016 15:24:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=gOkGNujSeKzFon5+rjZ87hvNUCOSYRttLD9wWRpGUZE=; b=EwpI0emz9/DyktW4ipVSlFI3BrOvxPKWzDU8rVVmedzfHSbBXPp1yCYZ3Nc+cpV9rN CO1tg/f9JUrzYFnHWYxKhgJhrX+1JO3hLKCqo6Kl8NAPPXBUxQRISlo5DsVKuW9xHhKZ M9JcMbNynDNuPw5lNB7vmkgHtciQonn7ymQZF6KQORuJV9xFbymJale3GjzzrnMiKzQk 0i54VO+c+ZG4DHRIsLDuH7rMesH27aaKjRw4VwlpMiIAeV0D8mltz1plrSSc93sAGtd+ X6s2P36gEEQepKrGBJq+lRC8//05zWaOlJOQeZAIcfXy4taGTmBv2TG5xgqDxZ2xT3Q2 IkTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=gOkGNujSeKzFon5+rjZ87hvNUCOSYRttLD9wWRpGUZE=; b=NtvqrvGcpJr++1nK7ubSxazjF0TlTKJ66Y4znwf48tahbJyqNDkSeLZhNgHk9PVCjF LAkUDH4qnn8SjN3dNG72ECiRnoeu0aBEmHNHSPbWAMwoHPc8H8QylMi4Slsw35ePJLJw cZVNsD7wpiRR1qFAU9p51jN7eMLWlegoYqc+qb9kelXxrSfbI7umVCREWNJWGsZ+uGZj zwpGG1jziPoY0FlMmRP77VipU5VedDrdHyvsI5fhax+PeItsZoDPGcsVS0YMBJheevsg pbgj3yI/owB6Rs2SqpWm2jX8Z/5jwVm9rH4K5eKRigJnlNJsNyLBNQ7THX3pZZXQVG7B b01Q== X-Gm-Message-State: AG10YOSKDRaEmTg/jI45dhKeT7J+RAGsUb3GF/1qSkk7REzkA2DAYpaMj4PKzgvNt/MVpvITJHy2Vm7xkq/5rg== X-Received: by 10.194.119.68 with SMTP id ks4mr47965606wjb.45.1455233048377; Thu, 11 Feb 2016 15:24:08 -0800 (PST) MIME-Version: 1.0 Sender: marc.sune@gmail.com Received: by 10.27.95.202 with HTTP; Thu, 11 Feb 2016 15:23:48 -0800 (PST) In-Reply-To: <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> <20160211152725.GF14424@autoinstall.dev.6wind.com> From: Marc Date: Fri, 12 Feb 2016 00:23:48 +0100 X-Google-Sender-Auth: xRkDCyhVw2kuLCBwUSJtkOW3Xj8 Message-ID: To: =?UTF-8?Q?N=C3=A9lio_Laranjeiro?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v5 3/4] ethdev: redesign link speed config API 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 Feb 2016 23:24:08 -0000 On 11 February 2016 at 16:27, N=C3=A9lio Laranjeiro wrote: > On Tue, Feb 02, 2016 at 11:30:59PM +0100, Marc wrote: > > On 2 February 2016 at 03:20, Stephen Hemminger < > stephen@networkplumber.org> > > wrote: > > > > > 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. > > > > > > > I see what you mean, but I am not sure I agree. Link speeds are > generally 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 > less > > readable and less maintainable (e.g. less "grepable"/"sedable") to me. > > > > > > > > > > If you are going to redo it, then just increase speed to 64 bit, and > allow > > > any non-zero value. > > > > > > > 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. > OK, since it is not performance critical I will change it to 64 bit value. > > > If there is consensus, I've no problem on removing it for v8 > Still the question about numeric speed MACROs is open. best marc > > > > Thanks > > marc > > [1] http://optics.org/news/4/1/29 > > -- > N=C3=A9lio Laranjeiro > 6WIND >