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 D100EA0350; Thu, 25 Jun 2020 22:04:54 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9B9505B3C; Thu, 25 Jun 2020 22:04:54 +0200 (CEST) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by dpdk.org (Postfix) with ESMTP id DCCE629CB for ; Thu, 25 Jun 2020 22:04:51 +0200 (CEST) Received: by mail-ed1-f46.google.com with SMTP id m21so5190669eds.13 for ; Thu, 25 Jun 2020 13:04:51 -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=6m/Q/rpVP+A+TMzevomdjWHk8rvweoMVjmb+jSnrYvU=; b=VENUYTLk00k7CbZTTDVvqV4MtKV3jm/Ii4SCgl/ADYGjSxyw1/R+lxYScUW/I/lnPS ZFpasKmGl6VfpbkTUxx1trjQFDKi63u8aRB8VRqFem3/ljBj5g8nVhJMhRhDqUaQShot KEiVu+MJegbI9FTu6bm23AVutYm9vZZmv1ND0= 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=6m/Q/rpVP+A+TMzevomdjWHk8rvweoMVjmb+jSnrYvU=; b=C+f4mFHS7nKe8FSxwjjxWyX/l23yeOGuohAaHp8q1fHZZFzdCufeQc5yHyGElWYutQ LFqD8ahaCHIdbHE0AiwZmTJvn4+mdh2a+WQOfvcGXuetBApo0qn4DYBSi8wYRSLdh7rD kHHJDxk7dY7DTER5yn2hbL9mIbjqqr6W6i36bGwOTZaUvX4thc7d5ln5BWQcDWVNTN/0 lZzYZyJGqyDzthpBY1QyXGJaWmMYzNADkpWUVKmL0PmmPPzDtpu8j5I/+mEMEPgXFkMZ sBofadnlgowupIREo8QdqqQGIFKBXS28VrRTBzuwBmhgXlkDbBGOBlFtFhwl1cBIC4Sn SR/A== X-Gm-Message-State: AOAM531Drr1j5UoBPkIn0QAHJBDO2Mnb61auf+7Fl4m+KxTgBIKtxQAt 63UBC92scNrKJ7pObQJi2JYSeMTrfWhz+pplMfq5 X-Google-Smtp-Source: ABdhPJxJjAKHAVDvEluFHolMQyrSxdLSBB0aWa76Yuoy37+kB74PjSyohe0KWzLK47rKUlbvIIkO2trIA7C4tkmeHeg= X-Received: by 2002:aa7:c69a:: with SMTP id n26mr33258102edq.2.1593115491552; Thu, 25 Jun 2020 13:04:51 -0700 (PDT) MIME-Version: 1.0 References: <9145227.bPS0MTqRLS@thomas> <4547208.FOi5bQ8hbg@thomas> <98CBD80474FA8B44BF855DF32C47DC35C610BC@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C610BC@smartserver.smartshare.dk> From: Daniel Kirichok Date: Thu, 25 Jun 2020 16:04:40 -0400 Message-ID: To: =?UTF-8?Q?Morten_Br=C3=B8rup?= Cc: Thomas Monjalon , Lincoln Lavoie , dts@dpdk.org, dev@dpdk.org, David Marchand , Ferruh Yigit , arybchenko@solarflare.com, i.dyukov@samsung.com, rasland@mellanox.com, James Hendergart Content-Type: multipart/alternative; boundary="000000000000f5e91305a8ee1ad9" 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" --000000000000f5e91305a8ee1ad9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 25, 2020 at 3:52 AM Morten Br=C3=B8rup wrote: > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > Sent: Wednesday, June 24, 2020 10:09 PM > > > > 24/06/2020 22:01, Lincoln Lavoie: > > > 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 > > > > > > Great! The physical layer rarely gets attention by DPDK, although it is > the foundation of everything. > > > > 24/06/2020 21:32, Daniel Kirichok: > > > > > The Speed Capabilities test will first check the speed of each > > interface > > > > > 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. > > > > Not sure we can trust kernel infos, especially for new HW. > > I agree. Otherwise we are depending on the kernel NIC driver development > being ahead of the DPDK driver development. > > > I was just trying to understand why ethtool came in the picture. > > I guess Lincoln is referring to some "ethtool" DPDK application, right? > > Dan > After doing some rethinking, I intend to use a tool with similar functionality to ethtool that is offered through the DPDK application. > > > > > > 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 detec= ted > > 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. > > As I understand it, this test verifies that the speed capabilities > reported by DPDK matches the expectations for that driver, where the > expectations are in the cfg file. This is good. > > There is no need to require any minimum speed. DPDK should be allowed to > support 10/100 Mbps Ethernet devices. > > Dan > Thanks for the clarification, I will incorporate this into the test. > > > > > > > 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? > > > > > > Tests to verify that the link actually comes up at the expected speeds > would be nice too: > > Verify that 10/100/1000 Mbps copper Ethernet devices link up at the speed > advertised by the tester using auto-negotiation, and at 10 and 100 Mbps > half duplex when the tester doesn't provide auto-negotiation ("Parallel > Detect" in IEEE 802.3 terminology). And similarly when the DUT sets the > advertised capabilities. > Dan > We were thinking to cover this through checking the config file depending on what the NIC is capable which could be multiple speeds, and the speed it is currently linked at which would be one speed. > Flow Control behavior should also be verified. If both tester and DUT > advertise Flow Control, the driver should use Flow Control, and if tester > and/or DUT advertises No Flow Control, the driver should not use flow > control. > > Dan > We were thinking to incorporate Flow Control behavior verification in a separate test case than this one since it would need to be confirmed that flow control is supported by the hardware before verifying for it. I don't have a lot of experience with multi-speed modules above 1 Gbps, but > guess similar tests apply here. > > And I agree that the tests should be limited to what can be automated wit= h > the tester. Running around pulling cables and swapping modules is not an > option. > > > --=20 Dan Kirichok UNH InterOperability Laboratory 21 Madbury Rd, Suite 100, Durham, NH 03824 dkirichok@iol.unh.edu www.iol.unh.edu --000000000000f5e91305a8ee1ad9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jun 25, 2020 at 3:52 AM Morte= n Br=C3=B8rup <mb@smartsharesystems.com> wrote:
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Wednesday, June 24, 2020 10:09 PM
>
> 24/06/2020 22:01, Lincoln Lavoie:
> > Inline.
> >
> > On Wed, Jun 24, 2020 at 3:55 PM Thomas Monjalon <thomas@monjalon.net>
> wrote:
> >
> > > Hi,
> > >
> > > A bit of context: Daniel is going to implement a test in DTS=
> > > for ethdev speed capability:
> > > http://doc.dpdk.org/g= uides/nics/features.html#speed-capabilities
> > >

Great! The physical layer rarely gets attention by DPDK, although it is the= foundation of everything.=C2=A0
> > > 24/06/2020 21:32, Daniel Kirichok:
> > > > The Speed Capabilities test will first check the speed = of each
> interface
> > > > that the device lists through ethtool.
> > >
> > > I assume you mean doing a query in Linux before starting DPD= K.
> >
> > LYL > I hadn't thought about that approach, we were thinki= ng we would
> > compare what the tested reports as the physical reality of the se= tup
> 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.
>
> Not sure we can trust kernel infos, especially for new HW.

I agree. Otherwise we are depending on the kernel NIC driver development be= ing ahead of the DPDK driver development.

> I was just trying to understand why ethtool came in the picture.

I guess Lincoln is referring to some "ethtool" DPDK application, = right?

=C2=A0
Dan >=C2=A0 After doing some reth= inking, I intend to use a tool with similar functionality to ethtool that i= s offered through the DPDK application.=C2=A0

>
> > > > 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.

As I understand it, this test verifies that the speed capabilities reported= by DPDK matches the expectations for that driver, where the expectations a= re in the cfg file. This is good.

There is no need to require any minimum speed. DPDK should be allowed to su= pport 10/100 Mbps Ethernet devices.

=C2=A0
Dan > Thanks for the clarificatio= n, I will incorporate this into the test.=C2=A0

> > >
> > > 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? autonegot= iation?
> > >
> > LYL > This would become highly dependent on the NIC, and it= 9;s
> > capabilities.=C2=A0 I have not had good luck with auto-neg on hig= h 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.=C2=A0 We're trying to av= oid 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?
>
>

Tests to verify that the link actually comes up at the expected speeds woul= d be nice too:

Verify that 10/100/1000 Mbps copper Ethernet devices link up at the speed a= dvertised by the tester using auto-negotiation, and at 10 and 100 Mbps half= duplex when the tester doesn't provide auto-negotiation ("Paralle= l Detect" in IEEE 802.3 terminology). And similarly when the DUT sets = the advertised capabilities.

Dan > W= e were thinking to cover this through checking the config file depending on= what the NIC is capable which=C2=A0could be multiple speeds, and the speed= it is currently linked at which would be one speed.
=C2=A0
=
Flow Control behavior should also be verified. If both tester and DUT adver= tise Flow Control, the driver should use Flow Control, and if tester and/or= DUT advertises No Flow Control, the driver should not use flow control.

Dan > We were thinking to incorpora= te Flow Control behavior verification in a separate test case than this one= since it would need to be confirmed that flow control is supported by the = hardware before verifying for it.=20 =C2=A0

I don't have a lot of experience with multi-speed modules above 1 Gbps,= but guess similar tests apply here.

And I agree that the tests should be limited to what can be automated with = the tester. Running around pulling cables and swapping modules is not an op= tion.




--

Dan Kirichok

UNH InterOperability Laboratory

21 Madbury Rd, Su= ite 100, Durham, NH 03824

dkirichok@iol.unh.edu

www.iol.unh.edu


=


--000000000000f5e91305a8ee1ad9--