From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 51C33A034F; Mon, 29 Mar 2021 14:05:47 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1141740151; Mon, 29 Mar 2021 14:05:47 +0200 (CEST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by mails.dpdk.org (Postfix) with ESMTP id 29AF140042 for <dev@dpdk.org>; Mon, 29 Mar 2021 14:05:46 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 4D1111546; Mon, 29 Mar 2021 08:05:42 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 29 Mar 2021 08:05:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= p0DN/AjwBmfCFjzlHA4edSDQEXkevsVtFZ3CHH8MLz4=; b=jnvZErslaeXqdrKV /WJb23Dy3HcImRukDtHX1gxr/BSWf3v3EgYW52TFMPi85otNMuSqBohvgwEM1NPw WLWf9ggVNMfauiSGNQ2yIl3DtFDCNR2QBT/RNlAHw8gNnudxZJw+ewH9cLU4ATh6 ZVT6t1d8B5h0ozIPOOq646Xgq2aBzXKldKIjVcHAsFbLBDm/bHSWvbPDVPoSnQMa 0wqaQubAEZEMoktWbsYB9J17AnxYCHEMfaM1RYQ5lm81C3UyJDvUIcXvhc3AB8Kc ckYekHVjIeFj/yfZPwMbzh8Yn+KsXsa7328LqTxQF/ck8g2LTYDSJwstcBBg1Pou ZR+gUw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=p0DN/AjwBmfCFjzlHA4edSDQEXkevsVtFZ3CHH8ML z4=; b=VsTP3eNQnx2wJgQiSd0JPoJfqqOpRdRA64UaQlmrNhLUc5+vSTraOrOLH 230k4laAOxUF7MFze+DKwH+kDKAyH49PVbvY1g1trHYGaZ0s/2klx9r76XsSAyOA w1bbC5rRPTzoq/us3aPwiZZBk/IzIKQ27VHApwljjVI8kVzc2j5rk+G0W/HmW+se NHNqV6Zs2M0bsgMv+HHbCzoK5eVIMSKXLcOm4z4Zax9EVRsX+Dpwc0wbJlfejQk9 03VXGTg7UeNly0yvD/ClKpYppF/GxCCI5cRT6ZJZoQePC91fsofINWoO/4lFYeQ1 Pl2SboRscN9ha8fLW8mWBoeVwi1Gw== X-ME-Sender: <xms:lMJhYFz8xUGA2dB8Gw7IEc7UWeaV0a_tL7tDBINSgsOwmU72UJy4cw> <xme:lMJhYFQ3zZZ_oYoOcp2LOe7KZY3bJ_2H0dGyqAFsLDo-Flj5YOzFfIsV-AFHpX4-0 1y3CJdMNQGQ6-hPyA> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudehkedggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepkeethedtieevhfeigeejleegudefjeehkeekteeuveeiuedvveeu tdejveehveetnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: <xmx:lMJhYPVe5mUW0k-NmaTxrVfoCthJWQ4svBgPSeqYGbjvFQPYyc9tdg> <xmx:lMJhYHj4JaGLEe1EBO-e15ZmyRWcFE6AqxuBZdWxzK1GaNDTzy3E7g> <xmx:lMJhYHBfShU7CDpakkPqnHyqxlqDFsV8VkaDTiODOsBGXwroQGYtBQ> <xmx:lcJhYONiAAtoMBu7N2WCByviUCFIB3iLTNpswIG-vVCHIyr7SUxySw> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 7708C1080057; Mon, 29 Mar 2021 08:05:39 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: Huisong Li <lihuisong@huawei.com> Cc: dev@dpdk.org, ferruh.yigit@intel.com, andrew.rybchenko@oktetlabs.ru, ajit.khaparde@broadcom.com, jerinj@marvell.com Date: Mon, 29 Mar 2021 14:05:37 +0200 Message-ID: <7625321.Bp9o7FevcO@thomas> In-Reply-To: <6db25f2c-3f87-d444-bfdf-530bdf7c87f8@huawei.com> References: <2a9f3c44-44da-854b-8b25-772a3570baa4@huawei.com> <7245184.973KLNHvPo@thomas> <6db25f2c-3f87-d444-bfdf-530bdf7c87f8@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] Questions about reporting auto-negotiation capability X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> 29/03/2021 13:44, Huisong Li: >=20 > =E5=9C=A8 2021/3/29 15:19, Thomas Monjalon =E5=86=99=E9=81=93: > > 29/03/2021 09:03, Thomas Monjalon: > >> 29/03/2021 06:02, Huisong Li: > >>> 'speed_capa' in struct rte_eth_dev_info is defined as follo= ws: > >>> > >>> uint32_t speed_capa; /**< Supported speeds bitmap (ETH_LINK_SPEED_).= */ > >>> > >>> > >>> Most PMD drivers use this field to report the speeds capabili= ty > >>> supported by the device to the upper-layer app. > >>> > >>> But it seems that few NICs report their auto-negotiation capability > >>> through this field. If NIC also uses it to report > >>> their auto-negotiation capability through this field, and should set = it > >>> to ETH_LINK_SPEED_AUTONEG(0) based on > >>> the definition of ETH_LINK_SPEED_xxx. In this case, it conflicts the > >>> report of the speeds capability . > >>> > >>> I don't know how to correctly report the auto-negotiation capability = of > >>> the device. Thanks for your reply. > >> ETH_LINK_SPEED_AUTONEG is not for capabilities. > >> Anyway, if it is set, it changes nothing (0) in the bitmap. > >> I see mlx5 is wrongly using it. > >> > >> speed_capa is only for enumerating speeds. > > I see some drivers are advertising ETH_LINK_SPEED_FIXED in speed_capa > > if the device cannot support autonegotiation. > > Should we add a note in doxygen? >=20 > Can we use bit 0 to indicate whether the device supports auto-negotiation? >=20 > Like, >=20 > 1/ If device doesn't support auto-negotiation, set bit(0) of the=20 > 'speed_capa' to 1, namely, "speed_capa |=3D ETH_LINK_SPEED_FIXED". Yes I think this is what FIXED means: cannot negotiate. > 2/ Other bits of the 'speed_capa' report all the speed capabilities=20 > supported by the device regardless of the value of bit(0) . >=20 > The above behavior is similar to cxgbe, bnxt, and mlx5. In this way,=20 > users can know whether the device supports auto-negotiation >=20 > based on bit(0) and detect the supported speed capabilities based on=20 > other bits. >=20 > After all, this 'speed_capa' and the 'link_speeds' in "rte_eth_conf"=20 > struct have different purposes.