From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by dpdk.org (Postfix) with ESMTP id CC8FD6A80 for ; Mon, 14 Sep 2015 12:02:37 +0200 (CEST) Received: by wiclk2 with SMTP id lk2so133373036wic.0 for ; Mon, 14 Sep 2015 03:02:37 -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=uYrtLNNlDdLxPJ4qrfIUKkJDL4PPQ7Aw4J5dHLrV1+k=; b=LmDjztAwMTgIKmwSx4z/m0k4TIUThWQrC3Fyyy5y2uEYlgnegst5WnhdozO+EwztPe dylWyMU+Wc/Mt0l9jpLvjXTY8U0v9JXvoCZVkB/hITaHOA1FKwGsLX0lhatFp00+wjC9 zbzxeL5hJj+EHh8p5FbDRlys5PeoNLGngzZd6kmA+sTa37h7xcpU6VhqvkwBC7qRsvHf jcZfAn0dBNKQfJr3Tm1/jKZHV8Eopoq7P+NBcg+mmzS1iUXA1YsOPwLHTAGBXeGCWebD wNjF4Bzz8Zdh026NxbQIVmRBza/nSlXVvzEBzYIsFHe1fu/FduKxLSVmzY0w7Xu05AXf ucCw== X-Gm-Message-State: ALoCoQmkfPKfALWk1PSKeoXavlbjoam8tK5GPN+j/I2auckn0PBN0kDtVb1TUuFzrS4Z4/Ida+4y X-Received: by 10.180.86.137 with SMTP id p9mr25069904wiz.38.1442224957623; Mon, 14 Sep 2015 03:02:37 -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 s9sm14668212wjy.16.2015.09.14.03.02.36 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 14 Sep 2015 03:02:37 -0700 (PDT) Date: Mon, 14 Sep 2015 12:02:22 +0200 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: Thomas Monjalon Message-ID: <20150914100222.GE25122@autoinstall.dev.6wind.com> References: <20150909131037.GA25122@autoinstall.dev.6wind.com> <2699193.9riTyGPe1z@xps13> <2046894.c3eJ0QZGuc@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2046894.c3eJ0QZGuc@xps13> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dev@dpdk.org, Morten =?iso-8859-1?Q?Br=F8rup?= 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: Mon, 14 Sep 2015 10:02:38 -0000 On Sun, Sep 13, 2015 at 11:18:33PM +0200, Thomas Monjalon wrote: > 2015-09-13 21:14, Marc Sune: > > 2015-09-09 15:33 GMT+02:00 Thomas Monjalon : > > > 2015-09-09 15:10, Nélio Laranjeiro: > > > > I think V2 is better, maybe you can add a function to convert a single > > > > bitmap value to the equivalent integer and get rid of ETH_SPEED_XXX > > > macros. > > > > > > > > Thomas what is your opinion? > > > > > > Your proposal looks good Nelio. > > > > I am confused, specially since you were the one advocating for having a > > unified set of constants for speeds (discussion in v2). > > Yes, my first thought was advocating an unification between capabilities and > negotiated link properties. > After I was convinced by Nelio's arguments: bitmap is good for capabilities > (especially to describe every capabilities in one field) but integer is better > for negotiated speed (especially for aggregated links). > Converting bitmap speed into integer should be easy to implement in a function. > > > In any case, as I see it, if we want to address the comments of M. Brorup: > > > > http://comments.gmane.org/gmane.comp.networking.dpdk.devel/19664 I read it. > > > > we need bitmaps for rte_eth_conf link_speed to set the advertised speeds. > > Yes I forgot this interesting comment. It is saying we need > 1/ capabilities > 2/ advertised modes (for auto-negotiation or fixed config) > 3/ negotiated mode > Previously we were focused only on 1/ and 3/. > 2/ was only limited to a mode configured without negotiation and was using the > same field as 3/. > Maybe we should really have 3 different fields. 1/ and 2/ would use a bitmap. > > > Let me know if you really want to come back to v2 or not. > > It needs more discussion. What do you think of the above proposal? > What is the opinion of Nelio? Morten? I agree with Morten, and with this proposition (we should be possible to disable some capabilities in the advertise field). For that we should have those 3 fields: 1/ Capability (as a bitmap), necessary for the user to configure the behavior of the PHY. 2/ Advertise (as a bitmap) to configure the PHY. 3/ speed, duplex, status (as rte_eth_link structure), necessary to verify that the configuration corresponds to what has been set and for other purposes. I still think Marc needs to go back to V2 and continue from this one. And as Thomas suggested, he could have a function to get rid of the double defines and use the sames ones for bitmap and non bitmap fields. Just for information, before I started this discussion I have worked on a patch to change the rte_eth_link.link_speed from 16 to 32 bit, I did not pushed it because, it should be pushed afters Marc's one, and it will need some rework after that. -- Nélio Laranjeiro 6WIND