From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6791643DAC; Mon, 1 Apr 2024 22:07:50 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E7F7C402A3; Mon, 1 Apr 2024 22:07:49 +0200 (CEST) Received: from fout8-smtp.messagingengine.com (fout8-smtp.messagingengine.com [103.168.172.151]) by mails.dpdk.org (Postfix) with ESMTP id 95AEE4029F for ; Mon, 1 Apr 2024 22:07:48 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfout.nyi.internal (Postfix) with ESMTP id E0CF61380119; Mon, 1 Apr 2024 16:07:47 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 01 Apr 2024 16:07:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1712002067; x=1712088467; bh=Sky1rFg9WQesfJtxEjVZ4QVW7cjuAn3Qc04jiNQfAFM=; b= mzvMSjzfEoUn8Y35duTwLBj4gjoYiy/9G2G3JS6lTuExyN0zu1Ltm2fvclKILRl0 JOoHSnkAetYRlNQIvsEt12KnxkCgFjVrV3TT6sY0U8RmlmYRWeRzQuJXTtp9ICgG 1m3DbqTeXGTC4ETKeHYK6leHg0bfIhUTF2Jj+QPhHeyMP9wqddqduBkbelzgfWtY nqaa4G7h5xNbWfLpG4dG83Egu+G2tqBNPw7k4STpLhhpBUO/vCA/QojyLGDqqq8r DyLnyMrxrhi2hh5hDQ6RBpBwDu9aq+6YsBvMI1B/myzehrSGUKaxspU309jveK9B RdtTYvWZZmQHQZv9NEqYQA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1712002067; x= 1712088467; bh=Sky1rFg9WQesfJtxEjVZ4QVW7cjuAn3Qc04jiNQfAFM=; b=X +bWRWh6UOQm/yYxI3yWV+yr2cpqjC+oa5Aw5FeXcS+R1BLjVNdPT9tlcDSe3cbd4 YDFR7CUhbTWW/YUWAexPPC6iTLPaRaBcITHXrN0c6GZOe8yXxmy9gj+5msmZ5pK+ q/CbBwhO+dbfq+lAIqcv/nr979SOf0+ZmglLThpAoiRfSQls3u2aglBfRFnEYoK1 hN5ckvzd9u7dsb7k7pEAjJfLfmPINvARDnlMkDUvX40642IlkqCX+mrsFfSneqwg pLZzRuAka4gQ/yLULEKaM0803GVc0UDvtq7wMcSvuouo3uLJD9FEFw1jL7PrIGKI sPdrNThwMcSAIaZ/7vciA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudeftddgudeghecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttdejnecuhfhrohhmpefvhhho mhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqne cuggftrfgrthhtvghrnhepjeduveehieevuddutdevfffgtdegkeeuveejffejgedtgeeg kefgvdeugfefkeejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 1 Apr 2024 16:07:44 -0400 (EDT) From: Thomas Monjalon To: huangdengdui Cc: Damodharam Ammepalli , Ajit Khaparde , "lihuisong (C)" , roretzla@linux.microsoft.com, dev@dpdk.org, ferruh.yigit@amd.com, aman.deep.singh@intel.com, yuying.zhang@intel.com, andrew.rybchenko@oktetlabs.ru, stephen@networkplumber.org, jerinjacobk@gmail.com, liuyonglong@huawei.com, fengchengwen@huawei.com, haijie1@huawei.com Subject: Re: [PATCH v2 1/6] ethdev: support setting lanes Date: Mon, 01 Apr 2024 22:07:43 +0200 Message-ID: <4326199.QLehXeTyEo@thomas> In-Reply-To: <5d2ab42c-4b56-4a40-8e0c-3ac9a5e34ec6@huawei.com> References: <20240312075238.3319480-4-huangdengdui@huawei.com> <5d2ab42c-4b56-4a40-8e0c-3ac9a5e34ec6@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 30/03/2024 12:38, huangdengdui: > But, there are different solutions for the device to report the setting > lane capability, as following: > 1. Like the current patch, reporting device capabilities in speed and > lane coupling mode. However, if we use this solution, we will have > to couple the the lanes setting with speed setting. > > 2. Like the Damodharam's RFC patch [1], the device reports the maximum > number of supported lanes. Users can config a lane randomly, > which is completely separated from the speed. > > 3. Similar to the FEC capability reported by a device, the device reports the > relationship table of the number of lanes supported by the speed, > for example: > speed lanes_capa > 50G 1,2 > 100G 1,2,4 > 200G 2,4 > > Options 1 and 2 have been discussed a lot above. > > For solution 1, the speed and lanes are over-coupled, and the implementation is too > complex. But I think it's easier to understand and easier for the device to report > capabilities. In addition, the ethtool reporting capability also uses this mode. > > For solution 2, as huisong said that user don't know what lanes should or can be set > for a specified speed on one NIC. > > I think that when the device reports the capability, the lanes should be associated > with the speed. In this way, users can know which lanes are supported by the current > speed and verify the configuration validity. > > So I think solution 3 is better. What do you think? I don't understand your proposals. Please could you show the function signature for each option?