From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by dpdk.org (Postfix) with ESMTP id D44B78DED for ; Tue, 8 Sep 2015 12:03:23 +0200 (CEST) Received: by wiclk2 with SMTP id lk2so113977928wic.0 for ; Tue, 08 Sep 2015 03:03:23 -0700 (PDT) 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=gLfe8sfNEVx32S1se09yDHGatnTBbT0n84NW5WOXHY4=; b=m3ay3ZWpC9lJl0fyV0SLUPg2BQMhT+WN+A3I/ZRdCOg74OQuuULN8lqbeMH6exag/A 3w0y9Xf+AmwLznI0l86AZRPwg1vAgu+L5Jgk6aarNtsAnjQsj8Pi97sC/jO0IE+0428n tI+qky2bOitZRXB5EY0yM/HXEdo3Ocn6hAThbiQOeX+4PKTDpwLBKf6D2lYCIhJCFZwu Y6seqDl22xgZt8Bw39g3HbFDQGUL9/ioFF0ultphXTMZ3P2hIvbgB1OdDl2MRx21IKZV n5blpeMnw6RL4xZ+l3/225+5ytPaivTZnFUFaiDpZLCBj4JDcsr7YcLa5dDpMg8BJ3TD tprQ== X-Gm-Message-State: ALoCoQnLzrHbvJ4X5/Up9XHGZcGKRIe5YPWY2/urwaEpsSDu7v1RAuHxXVzntTF9vlHa7xhdskSB X-Received: by 10.180.21.137 with SMTP id v9mr42209153wie.8.1441706603663; Tue, 08 Sep 2015 03:03:23 -0700 (PDT) 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 ul1sm3934915wjc.30.2015.09.08.03.03.22 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 08 Sep 2015 03:03:23 -0700 (PDT) Date: Tue, 8 Sep 2015 12:03:09 +0200 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: Marc Sune Message-ID: <20150908100309.GE10297@autoinstall.dev.6wind.com> References: <1440804014-30815-1-git-send-email-marc.sune@bisdn.de> <1440807373-24770-1-git-send-email-marc.sune@bisdn.de> 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.21 (2010-09-15) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v4 0/2] ethdev: add port speed capability bitmap 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: Tue, 08 Sep 2015 10:03:24 -0000 On Mon, Sep 07, 2015 at 10:52:53PM +0200, Marc Sune wrote: > 2015-08-29 2:16 GMT+02:00 Marc Sune : > > > The current rte_eth_dev_info abstraction does not provide any mechanism to > > get the supported speed(s) of an ethdev. > > > > For some drivers (e.g. ixgbe), an educated guess can be done based on the > > driver's name (driver_name in rte_eth_dev_info), see: > > > > http://dpdk.org/ml/archives/dev/2013-August/000412.html > > > > However, i) doing string comparisons is annoying, and can silently > > break existing applications if PMDs change their names ii) it does not > > provide all the supported capabilities of the ethdev iii) for some drivers > > it > > is impossible determine correctly the (max) speed by the application > > (e.g. in i40, distinguish between XL710 and X710). > > > > This small patch adds speed_capa bitmap in rte_eth_dev_info, which is > > filled > > by the PMDs according to the physical device capabilities. > > > > v2: rebase, converted speed_capa into 32 bits bitmap, fixed alignment > > (checkpatch). > > > > v3: rebase to v2.1. unified ETH_LINK_SPEED and ETH_SPEED_CAP into > > ETH_SPEED. > > Converted field speed in struct rte_eth_conf to speeds, to allow a > > bitmap > > for defining the announced speeds, as suggested by M. Brorup. Fixed > > spelling issues. > > > > v4: fixed errata in the documentation of field speeds of rte_eth_conf, and > > commit 1/2 message. rebased to v2.1.0. v3 was incorrectly based on > > ~2.1.0-rc1. > > > > Thomas, > > Since mostly you were commenting for v1 and v2; any opinion on this one? > > Regards > marc Hi Marc, I have read your patches, and there are a few mistakes, for instance mlx4 (ConnectX-3 devices) does not support 100Gbps. In addition, it seems your new bitmap does not support all kind of speeds, take a look at the header of Ethtool, in the Linux kernel (include/uapi/linux/ethtool.h) which already consumes 30bits without even managing speeds above 56Gbps. It would be nice to keep the field to represent the real speed of the link, in case it is not represented by the bitmap, it could be also useful for aggregated links (bonding for instance). The current API already works this way, it just needs to be extended from 16 to 32 bit to manage speed above 64Gbps. >[...] Nélio -- Nélio Laranjeiro 6WIND