Re: [dpdk-dev] Speed Capabilities Feature

[Thomas Monjalon <thomas@monjalon.net>]

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?