DPDK patches and discussions
 help / color / mirror / Atom feed
From: Lincoln Lavoie <lylavoie@iol.unh.edu>
To: Thomas Monjalon <thomas@monjalon.net>
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: [dpdk-dev] Speed Capabilities Feature
Date: Wed, 24 Jun 2020 16:01:04 -0400	[thread overview]
Message-ID: <CAOE1vsNhKbDDewoFmmn6RxGMhffU8APQBF82FEPAQfP_NAK_iQ@mail.gmail.com> (raw)
In-Reply-To: <9145227.bPS0MTqRLS@thomas>

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.

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




-- 
*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)
<https://www.iol.unh.edu/>

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

Thread overview: 6+ 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 [this message]
2020-06-24 20:09     ` Thomas Monjalon
2020-06-25  7:52       ` Morten Brørup
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=CAOE1vsNhKbDDewoFmmn6RxGMhffU8APQBF82FEPAQfP_NAK_iQ@mail.gmail.com \
    --to=lylavoie@iol.unh.edu \
    --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=mb@smartsharesystems.com \
    --cc=rasland@mellanox.com \
    --cc=thomas@monjalon.net \
    /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).