test suite reviews and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Lincoln Lavoie <lylavoie@iol.unh.edu>
Cc: Daniel Kirichok <dkirichok@iol.unh.edu>,
	dts@dpdk.org, dev@dpdk.org,
	David Marchand <david.marchand@redhat.com>,
	Ferruh Yigit <ferruh.yigit@intel.com>,
	arybchenko@solarflare.com, mb@smartsharesystems.com,
	i.dyukov@samsung.com, rasland@mellanox.com,
	James Hendergart <j.hendergart@f5.com>
Subject: Re: [dts] Speed Capabilities Feature
Date: Wed, 24 Jun 2020 22:09:21 +0200	[thread overview]
Message-ID: <4547208.FOi5bQ8hbg@thomas> (raw)
In-Reply-To: <CAOE1vsNhKbDDewoFmmn6RxGMhffU8APQBF82FEPAQfP_NAK_iQ@mail.gmail.com>

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/guides/nics/features.html#speed-capabilities
> >
> > 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 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’t 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?



  reply	other threads:[~2020-06-24 20:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-24 19:32 Daniel Kirichok
2020-06-24 19:55 ` Thomas Monjalon
2020-06-24 20:01   ` Lincoln Lavoie
2020-06-24 20:09     ` Thomas Monjalon [this message]
     [not found]       ` <98CBD80474FA8B44BF855DF32C47DC35C610BC@smartserver.smartshare.dk>
2020-06-25 20:04         ` Daniel Kirichok

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4547208.FOi5bQ8hbg@thomas \
    --to=thomas@monjalon.net \
    --cc=arybchenko@solarflare.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=dkirichok@iol.unh.edu \
    --cc=dts@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=i.dyukov@samsung.com \
    --cc=j.hendergart@f5.com \
    --cc=lylavoie@iol.unh.edu \
    --cc=mb@smartsharesystems.com \
    --cc=rasland@mellanox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).