From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=krziKeDEnZDhtRE0Nr+/+ox0VMJVQWLxjsG058pIej8=; b=venTcIy/o0z9eghgyKzvPoCm/RBMUFdccSsgwfIYOQgpbwoQqsZ5thBC0OHSaCMAM5 xMrcwFdeJ6cvuzdmdFbrEHA6W6ycZa6zy4d/r3G+p8bfD6ISw0XQ5IrOLsn4XS7yKcjk vOD0zaUP3+FUHTnAwQinhsRSxw6QcVZvdTetMCPnzqPQfMBlvWz3YHZF3RCtBY4aXt/g QRHSG2TFXSwG1m0HMLsbLuqMIBg1Tmc+yhD4mGkSYsLTklR8XB5So/AGsdaj1gj0x0gW Ql/Xl91LyStnHeH3WcjmoCU8jRk1AUi5XVSCh/0NWya4fcTEgOiUeT8K7vs4PN7LgGTM KOow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=krziKeDEnZDhtRE0Nr+/+ox0VMJVQWLxjsG058pIej8=; b=LPtkBL2U0nJvuHcZ+MEfFYHDUi/OIeD13eRXm/9qD/Pj6H4demvYaUFUZPyv40JYdh 0QQ52H3sG4klf5BTIxRmAycEQUKQxn37HuHZcbncXOoji/c8SX5n+wI4aVjqcmJAjWO+ Nr6zLDJmTsCOApmcFJtt/QumE4kWAjExXF9rcu2fgMj23xdjqLKDhYdCCKQ9qoHP7fOp AWjulLepY8Jrs7/JV0pABZC4auywW2qs0hNMGQ+YEgQirY0rkcfhXHWN0AOxYTq7Aedx R90YT++vjE0vz++GAf4/FMth5QKmcxqdd9Th+Hw9T93ZSl7q/4rA6NR0ZRwTmfoIc1Rc JaSA== X-Gm-Message-State: AG10YOT81h1gRWsYNjhneoNiTnCV5Il95LFpNRnKYnKJlIt35RLztPZN74OZp5WF003xmJw1 X-Received: by 10.194.172.97 with SMTP id bb1mr52023908wjc.173.1455204463113; Thu, 11 Feb 2016 07:27:43 -0800 (PST) Received: from autoinstall.dev.6wind.com (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id e19sm24492117wmd.1.2016.02.11.07.27.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Feb 2016 07:27:42 -0800 (PST) Date: Thu, 11 Feb 2016 16:27:25 +0100 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: Marc 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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 15:27:43 -0000 On Tue, Feb 02, 2016 at 11:30:59PM +0100, Marc wrote: > On 2 February 2016 at 03:20, Stephen Hemminger > 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. > If there is consensus, I've no problem on removing it for v8 > > Thanks > marc [1] http://optics.org/news/4/1/29 -- Nélio Laranjeiro 6WIND