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 0B1DDA0350; Wed, 24 Jun 2020 22:01:40 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CE1D31D9FC; Wed, 24 Jun 2020 22:01:39 +0200 (CEST) Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) by dpdk.org (Postfix) with ESMTP id 20DC51D9E9 for ; Wed, 24 Jun 2020 22:01:39 +0200 (CEST) Received: by mail-ej1-f42.google.com with SMTP id i14so3671423ejr.9 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=RyTl/P1xu4Nv7fC0XkcbVgq1tk0oC71yd0eWZ1iTqaXpGUYVvEURNdTtEo/ulOvaSV iKwLe5euH4ckDJ3QfgS0Pd45GajYd31D+pQyuYdpBJW4OEdQMq3pKtUC2FqVr7bN7UFR gMyxbZrNtu1wH2cgePCwu1mzDmLPxISaeAHVLzPwgHA4H7Zk5pzj4TvDK/IKLxpPBnR1 y4JE54/UrjjmNurUIkLgHKvWvxH9VhkgzE1yRMwmgfrrHzPe0GiJniK1IjHkyLQw1Hfi K8ioLmuL1cIuZllx353FYkymy5xkPStP6sgmlkuihckLvRqofY8GKMTiygd20cVhLI38 Vlqw== X-Gm-Message-State: AOAM533Lh02hLasJebiMIf72lbHmGSHjLZnf+pQu1VyLlRlkGm/dJf/w UIOpEuaD5N0tZIm/U43sUs7m4lwCSkvHGktXQrJ8fw== 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: multipart/alternative; boundary="0000000000009f6d1b05a8d9f141" Subject: Re: [dts] Speed Capabilities Feature X-BeenThere: dts@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: test suite reviews and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dts-bounces@dpdk.org Sender: "dts" --0000000000009f6d1b05a8d9f141 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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) --0000000000009f6d1b05a8d9f141 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Inline.

On Wed, Jun 24, 2020 at 3:55 PM Thomas Monjalon = <thomas@monjalon.net> wrot= e:
Hi,

A bit of context: Daniel is going to implement a test in DTS
for ethdev speed capability:
http://doc.dpdk.org/guides/nics/feat= ures.html#speed-capabilities

24/06/2020 21:32, Daniel Kirichok:
> The Speed Capabilities test will first check the speed of each interfa= ce
> that the device lists through ethtool.

I assume you mean doing a query in Linux before starting DPDK.

L= YL > I hadn't thought about that approach, we were thinking we would= compare what the tested reports as the physical=C2=A0reality of the setup = with what the DPDK driver reports.
If you think we can trust the native kernel=C2=A0drive= rs as the source=C2=A0of 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<= br> > 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 s= peed 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 &g= t; This would become highly dependent on the NIC, and it's capabilities= .=C2=A0 I have not had good luck with auto-neg on high speed links like 10G= SPF and higher. Similarly, high speed links would likely=C2=A0
require a physical=C2=A0ch= ange (assuming the NIC supported multiple speeds), to change either the mod= ule or the DAC.=C2=A0 We're trying to avoid anything that would require= physical changes that can't be forced through=C2=A0
the tester (i.e. disable the port= connected to the DUT for a link down, etc.)

=C2=A0


--
Lincoln Lavoie
Senior E= ngineer, Broadband Technologies
21 Madbury Rd., Ste. 100, Durham,= NH 03824
+1-603-674-2755 (m)<= br>
=
--0000000000009f6d1b05a8d9f141--