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 31E669AD8 for ; Thu, 11 Jun 2015 11:09:14 +0200 (CEST) Received: by wifx6 with SMTP id x6so3862544wif.0 for ; Thu, 11 Jun 2015 02:09:13 -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=7A5o6wklNcm41JXOOKX1e0lwJylWcUSyfmiJoJ0sOFo=; b=VVy4mUFUd58N/fVbgByBDtFM2X3kkdkAXwgZSh2y5s2Bh9e1Z3dFS0/OBAyHrWkmv4 WwMIdcQzapNq/bDP8h9pgPKtSfc+T+5xE35aI5nZllvAfdU8EGUgsk3cUUW3O0HK2iEz Bi7iqODieBkybnnsNmxSg1VpxJIsJ3dN5YYgigxk/aYjSvP1XCjRM3NfPaO9Hy4+RHxW HpGCESrcArJs919UFpJX4caq8NsPIu0CZvSeSfNRNHYyDW+dQzZlnqd4+XP8vV6Mwq2c iPHTkk3vgZ3XS6SI5RzQLLcL4D6SKqyjk68lOf/TITnaYYx7rinXlQD/Yp+dKhD1uIBj qlrg== X-Gm-Message-State: ALoCoQkZ+LaQTeeVgE+cq3i3FTZH5unhCMP5/cuJxI1nzIWjElU3uYhx+M2gVzw3TetMEF7LCo62 X-Received: by 10.194.120.106 with SMTP id lb10mr14941898wjb.54.1434013753640; Thu, 11 Jun 2015 02:09:13 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id a8sm11841305wic.22.2015.06.11.02.09.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jun 2015 02:09:12 -0700 (PDT) From: Thomas Monjalon To: Marc Sune Date: Thu, 11 Jun 2015 11:08:17 +0200 Message-ID: <5698652.MiVIRsgeEt@xps13> Organization: 6WIND User-Agent: KMail/4.14.8 (Linux/4.0.4-2-ARCH; KDE/4.14.8; x86_64; ; ) In-Reply-To: <55755754.4070508@bisdn.de> References: <1431387946-29950-1-git-send-email-marc.sune@bisdn.de> <5394923.Bu4Z07Mj4A@xps13> <55755754.4070508@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: Thu, 11 Jun 2015 09:09:14 -0000 2015-06-08 10:50, Marc Sune: > On 29/05/15 20:23, Thomas Monjalon wrote: > > 2015-05-27 11:15, Marc Sune: > >> On 27/05/15 06:02, Thomas Monjalon wrote: > >>>> +#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? > > Me. I tried implementing this unified speed constantss, but the problem > is that for the capabilities full-duplex/half-duplex speeds are unrolled > (e.g. 100M_HD/100_FD). There is no generic 100M to set a specific speed, Or we can define ETH_SPEED_CAP_100M and ETH_SPEED_CAP_100M_FD. Is it possible to have a NIC doing 100M_FD but not 100M_HD? > so if you want a fiex speed and duplex auto-negociation witht the > current set of constants, it would look weird; e.g. > link_speed=ETH_SPEED_100M_HD and then set > link_duplex=ETH_LINK_AUTONEG_DUPLEX): > > 232 struct rte_eth_link { > 233 uint16_t link_speed; /**< ETH_LINK_SPEED_[10, 100, > 1000, 10000] */ > 234 uint16_t link_duplex; /**< ETH_LINK_[HALF_DUPLEX, > FULL_DUPLEX] */ > 235 uint8_t link_status : 1; /**< 1 -> link up, 0 -> link > down */ > 236 }__attribute__((aligned(8))); /**< aligned for atomic64 > read/write */ > > There is another minor point, which is when setting the speed in > rte_eth_conf: > > 840 struct rte_eth_conf { > 841 uint16_t link_speed; > 842 /**< ETH_LINK_SPEED_10[0|00|000], or 0 for autonegotation */ > > 0 is used for speed auto-negociation, but 0 is also used in the > capabilities bitmap to indicate no PHY_MEDIA (virtual interface). I > would have to define something like: > > 906 #define ETH_SPEED_NOT_PHY (0) /*< No phy media > */ > 907 #define ETH_SPEED_AUTONEG (0) /*< Autonegociate speed > */ Or something like SPEED_UNDEFINED > And use (only) NOT_PHY for a capabilities and _AUTONEG for rte_eth_conf. > > The options I see: > > a) add to the the list of the current speeds generic 10M/100M/1G speeds > without HD/FD, and just use these speeds in rte_eth_conf. > b) leave them separated. > > I would vote for b), since the a) is not completely clean. > Opinions&other alternatives welcome. > > Marc