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 E0780A0350; Wed, 24 Jun 2020 22:01:41 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0BDBB1DA0C; Wed, 24 Jun 2020 22:01:40 +0200 (CEST) Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) by dpdk.org (Postfix) with ESMTP id 29B411D9DF for ; Wed, 24 Jun 2020 22:01:39 +0200 (CEST) Received: by mail-ej1-f46.google.com with SMTP id dp18so3674654ejc.8 for ; Wed, 24 Jun 2020 13:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UiOt+O7r0+3LTTVqbU41SlWEbHiN2wFrsbL0YZqj7Q4=; b=R2RSWTfTTGs2XpJlY+dNKhsRVf6FlRnQCtg60t5DUBUGU1cAojWcodhKF9yOnLK6s5 p7v1/lasf//QHBGr8Lf7sN1DiY5J66I8eXYiefgnqW19ze5Irr7XnB563kvjxvRm3I4h BBMVvYPME0+01U6TAtmP4XC1THYFlRzdjsC9I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UiOt+O7r0+3LTTVqbU41SlWEbHiN2wFrsbL0YZqj7Q4=; b=Yyoc0PMe8TuEVVZGYdzoIvvG21dOMuQPv3DkkAE/Uome+RSq0npqmvVnHpIa35qjh+ HlA/OmdB82GDAPj/oYJI51SurizTY5jfavj82H/wf6G2T5WsMuRswtFNW0zFd8UXgdy8 y39cvoAByAUwB+fGnOP1HOmNDEr4k4uojj6ypvd/KPtHJdE6QlGwL7qrEybcLdCA7Bz8 oKatrZC2yl4+MJsyNYOOkTYb9UL0MRfm8CUFpuKp5BStiRWsHzC8/SeEj+PKnB+c33ie ysbzW1JEX4VHnZ3hdVSo1re9E/jW22V9/3OboNwSU7bmqUoOEWZIJ70GKrKwLcPwK3XB hRvA== X-Gm-Message-State: AOAM5312MZISFWy8QajFSl5tnfDp9XMGjAXIxVu6fdoGNbd4745yokBK IkGqTbNqKTfxqChvukgOaJSro71wkdqK1HslctM1mA== X-Google-Smtp-Source: ABdhPJwFo3LLndpUebVbyl0tXNSr2b3/7TURXegS8svYudxWSCFWpmcjBlOJtIIb/mkA+C+vhtydceJQDOnN0IEhoLA= X-Received: by 2002:a17:907:1059:: with SMTP id oy25mr5473137ejb.90.1593028898668; Wed, 24 Jun 2020 13:01:38 -0700 (PDT) MIME-Version: 1.0 References: <9145227.bPS0MTqRLS@thomas> In-Reply-To: <9145227.bPS0MTqRLS@thomas> From: Lincoln Lavoie Date: Wed, 24 Jun 2020 16:01:04 -0400 Message-ID: To: Thomas Monjalon 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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" Inline. On Wed, Jun 24, 2020 at 3:55 PM Thomas Monjalon wrote= : > 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 interfac= e > > that the device lists through ethtool. > > I assume you mean doing a query in Linux before starting DPDK. > 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 truth, we could read those first and compare DPDK output. > > > 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 sp= eed 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.) --=20 *Lincoln Lavoie* Senior Engineer, Broadband Technologies 21 Madbury Rd., Ste. 100, Durham, NH 03824 lylavoie@iol.unh.edu https://www.iol.unh.edu +1-603-674-2755 (m)