<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Inline.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 24, 2020 at 3:55 PM Thomas Monjalon <<a href="mailto:thomas@monjalon.net">thomas@monjalon.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
A bit of context: Daniel is going to implement a test in DTS<br>
for ethdev speed capability:<br>
<a href="http://doc.dpdk.org/guides/nics/features.html#speed-capabilities" rel="noreferrer" target="_blank">http://doc.dpdk.org/guides/nics/features.html#speed-capabilities</a><br>
<br>
24/06/2020 21:32, Daniel Kirichok:<br>
> The Speed Capabilities test will first check the speed of each interface<br>
> that the device lists through ethtool.<br>
<br>
I assume you mean doing a query in Linux before starting DPDK.<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small">If you think we can trust the native kernel drivers as the source of truth, we could read those first and compare DPDK output.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Then it compares each interface<br>
> speed to a user-defined set of expected speeds set in a newly created<br>
> config file, `speed_capabilities.cfg`.<br>
<br>
Why do you need such config file?<br>
<br>
> The test fails if an interface is<br>
> found that isn’t accounted for in the cfg file, the detected speed is less<br>
> than 1 Gb/s, or an interface detects a different speed than what is<br>
> expected from the cfg file. Otherwise, it passes.<br>
<br>
So you don't test DPDK?<br>
<br>
Would be interesting to compare the actual link speed<br>
from rte_eth_link_get() with the advertised capability.<br>
<br>
What else do we want to test regarding link speed? autonegotiation?<br></blockquote><div><div class="gmail_default" style="font-size:small">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 </div><div class="gmail_default" style="font-size:small">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 </div><div class="gmail_default" style="font-size:small">the tester (i.e. disable the port connected to the DUT for a link down, etc.)</div><br></div><div> </div></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><b>Lincoln Lavoie</b><br></div><div>Senior Engineer, Broadband Technologies</div><div>21 Madbury Rd., Ste. 100, Durham, NH 03824</div><div><a href="mailto:lylavoie@iol.unh.edu" target="_blank">lylavoie@iol.unh.edu</a></div><div><a href="https://www.iol.unh.edu" target="_blank">https://www.iol.unh.edu</a></div><div>+1-603-674-2755 (m)<br></div><div><a href="https://www.iol.unh.edu/" target="_blank"><img src="http://homeautomation.lavoieholdings.com/_/rsrc/1390068882701/unh-iol-logo.png"></a></div></div></div></div></div></div></div></div></div></div></div></div></div>