From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 879B5A0350; Wed, 24 Jun 2020 22:09:26 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 196C91D913; Wed, 24 Jun 2020 22:09:26 +0200 (CEST) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by dpdk.org (Postfix) with ESMTP id 623A91D708; Wed, 24 Jun 2020 22:09:25 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id DCF19580589; Wed, 24 Jun 2020 16:09:24 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 24 Jun 2020 16:09:24 -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=fm1; bh= A8v0bdeDpZDtjUp0gQTSTQbP3OyhRnmULqU9/EHh+5Y=; b=P3P39LLw/35RMejh 7sQndQgRrWNFu/26+8qcSCrJoZjeKWifpNdW2LlYDmANgv0MNbkjZ++wdlz68q44 sn5wBq1+62fSPRnmf0AVg3yr2F6ocVl37+6AorRTpBwF6idr4MN+D7r5ZvCeMOfa JZQOUPmYiPxJ9QcymEo3DRLVIAIt6SjzpyKnTzcaQRF21Xx2MtkxOiC6Z+uwpTcK pLHintjViNEa7g5MRNJJzTbc3ym8//kGmhFleCv/Y63QinIBHGFU1tpQKsUYSVz+ wVApdHqVS6Arl2FPN3lmiAhGgSdFYtb+mlD6YhUx+ymSCobJAasE3yq18dzmdRN9 cZQu+g== 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=fm3; bh=A8v0bdeDpZDtjUp0gQTSTQbP3OyhRnmULqU9/EHh+ 5Y=; b=iTV6EDEkkjhkSYItTeq3ynNam189Qo10TcZzSUnf5/chCcrSI0fqhiKGW qEy/kDgw/qOAoobi9tWDuvGqqrCUpuDPe+OA4RMX/BCxMz4COW+Q0RBd3mDXpoNX c+fBmqyXztkdL9n8sCdOFuRQtThmHzNa5ntzc5r1fGGVbIfj1ryNcKdYHq4QDBmL UeFSgyh/YsJNSu4CtrKLKuMrXMQ5NVTA9Nwx6w4w/PPnLIZy5S2NeyolRIEOpkjP dt3+ejoqW+vSv4x3ERjLCmYAoWAsMg2eNZrT293FDJQXcC5ufd/NHmIr49prBhGG HgEgrobbVU8ZfZaaSbhHdU5WMxn0g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekjedgudegudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedvkeetveeihfegfedtfeejueekkeekueevgfejuedviedvvdev uefgteevtdefveenucffohhmrghinhepughpughkrdhorhhgnecukfhppeejjedrudefge drvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 007593280059; Wed, 24 Jun 2020 16:09:22 -0400 (EDT) From: Thomas Monjalon To: Lincoln Lavoie Cc: Daniel Kirichok , dts@dpdk.org, dev@dpdk.org, David Marchand , Ferruh Yigit , arybchenko@solarflare.com, mb@smartsharesystems.com, i.dyukov@samsung.com, rasland@mellanox.com, James Hendergart Date: Wed, 24 Jun 2020 22:09:21 +0200 Message-ID: <4547208.FOi5bQ8hbg@thomas> In-Reply-To: References: <9145227.bPS0MTqRLS@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] Speed Capabilities Feature X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 24/06/2020 22:01, Lincoln Lavoie: > Inline. >=20 > On Wed, Jun 24, 2020 at 3:55 PM Thomas Monjalon wro= te: >=20 > > Hi, > > > > A bit of context: Daniel is going to implement a test in DTS > > for ethdev speed capability: > > http://doc.dpdk.org/guides/nics/features.html#speed-capabilities > > > > 24/06/2020 21:32, Daniel Kirichok: > > > The Speed Capabilities test will first check the speed of each interf= ace > > > that the device lists through ethtool. > > > > I assume you mean doing a query in Linux before starting DPDK. >=20 > LYL > I hadn't thought about that approach, we were thinking we would > compare what the tested reports as the physical reality of the setup with > what the DPDK driver reports. > If you think we can trust the native kernel drivers as the source of trut= h, > we could read those first and compare DPDK output. Not sure we can trust kernel infos, especially for new HW. I was just trying to understand why ethtool came in the picture. > > > Then it compares each interface > > > speed to a user-defined set of expected speeds set in a newly created > > > config file, `speed_capabilities.cfg`. > > > > Why do you need such config file? > > > > > The test fails if an interface is > > > found that isn=E2=80=99t accounted for in the cfg file, the detected = speed is > > less > > > than 1 Gb/s, or an interface detects a different speed than what is > > > expected from the cfg file. Otherwise, it passes. > > > > So you don't test DPDK? > > > > Would be interesting to compare the actual link speed > > from rte_eth_link_get() with the advertised capability. > > > > What else do we want to test regarding link speed? autonegotiation? > > > LYL > This would become highly dependent on the NIC, and it's > capabilities. I have not had good luck with auto-neg on high speed links > like 10G SPF and higher. Similarly, high speed links would likely > require a physical change (assuming the NIC supported multiple speeds), to > change either the module or the DAC. We're trying to avoid anything that > would require physical changes that can't be forced through > the tester (i.e. disable the port connected to the DUT for a link down, > etc.) At least, we can test that autonegotiation is establishing a speed advertised in capabilities, right?