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
+1-603-674-2755 (m)