test suite reviews and discussions
 help / color / Atom feed
* [dts] Speed Capabilities Feature
@ 2020-06-24 19:32 Daniel Kirichok
  2020-06-24 19:55 ` Thomas Monjalon
  0 siblings, 1 reply; 5+ messages in thread
From: Daniel Kirichok @ 2020-06-24 19:32 UTC (permalink / raw)
  To: dts, dev
  Cc: Lincoln Lavoie, david.marchand, thomas, ferruh.yigit, arybchenko,
	mb, i.dyukov, rasland

[-- Attachment #1: Type: text/plain, Size: 719 bytes --]

Hi all,

The Speed Capabilities test will first check the speed of each interface
that the device lists through ethtool. Then it compares each interface
speed to a user-defined set of expected speeds set in a newly created
config file, `speed_capabilities.cfg`. 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.

Let me know if there are any comments or questions.

Thanks,
Dan

-- 

Dan Kirichok

UNH InterOperability Laboratory

21 Madbury Rd, Suite 100, Durham, NH 03824

dkirichok@iol.unh.edu

www.iol.unh.edu

[-- Attachment #2: Type: text/html, Size: 2788 bytes --]

<div dir="ltr">Hi all,<div><br></div><div>The Speed Capabilities test will first check the speed of each interface that the device lists through ethtool. Then it compares each interface speed to a user-defined set of expected speeds set in a newly created config file, `speed_capabilities.cfg`. 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. <br clear="all"><div><br></div><div>Let me know if there are any comments or questions. </div><div><br></div><div>Thanks,</div><div>Dan</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><span><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Dan Kirichok </span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">UNH InterOperability Laboratory</span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">21 Madbury Rd, Suite 100, Durham, NH 03824</span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;font-family:Arial;color:rgb(17,85,204);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><a href="mailto:dkirichok@iol.unh.edu" target="_blank">dkirichok@iol.unh.edu</a></span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><a href="http://www.iol.unh.edu/" style="background-color:transparent;font-family:Arial;font-size:10pt;white-space:pre-wrap" target="_blank">www.iol.unh.edu</a><br></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><br></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;font-family:Arial;color:rgb(51,51,51);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><img src="https://lh4.googleusercontent.com/PiGr1LaEiC-EkbE7843LHDkVaXFGXwW1Yq2aTfjqzd4i2Qg4CTl2icsDGzMw7dKAZpsr-ofI7V45PIFuH3dmnEy-TXRMf5i10fUBwx-NxZUtk1aCK48Y-UX9L5qDtl1YkMb1Wl0" width="150" height="37" style="border:none"></span></p><div><span style="font-size:10pt;font-family:Arial;color:rgb(51,51,51);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><br></span></div></span></div></div></div>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dts] Speed Capabilities Feature
  2020-06-24 19:32 [dts] Speed Capabilities Feature Daniel Kirichok
@ 2020-06-24 19:55 ` Thomas Monjalon
  2020-06-24 20:01   ` Lincoln Lavoie
  0 siblings, 1 reply; 5+ messages in thread
From: Thomas Monjalon @ 2020-06-24 19:55 UTC (permalink / raw)
  To: Daniel Kirichok
  Cc: dts, dev, Lincoln Lavoie, david.marchand, ferruh.yigit,
	arybchenko, mb, i.dyukov, rasland, j.hendergart

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.

> 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?



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dts] Speed Capabilities Feature
  2020-06-24 19:55 ` Thomas Monjalon
@ 2020-06-24 20:01   ` Lincoln Lavoie
  2020-06-24 20:09     ` Thomas Monjalon
  0 siblings, 1 reply; 5+ messages in thread
From: Lincoln Lavoie @ 2020-06-24 20:01 UTC (permalink / raw)
  To: Thomas Monjalon
  Cc: Daniel Kirichok, dts, dev, David Marchand, Ferruh Yigit,
	arybchenko, mb, i.dyukov, rasland, James Hendergart

[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]

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/>

[-- Attachment #2: Type: text/html, Size: 3800 bytes --]

<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 &lt;<a href="mailto:thomas@monjalon.net">thomas@monjalon.net</a>&gt; 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>
&gt; The Speed Capabilities test will first check the speed of each interface<br>
&gt; 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 &gt; I hadn&#39;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>
&gt; Then it compares each interface<br>
&gt; speed to a user-defined set of expected speeds set in a newly created<br>
&gt; config file, `speed_capabilities.cfg`.<br>
<br>
Why do you need such config file?<br>
<br>
&gt; The test fails if an interface is<br>
&gt; found that isn’t accounted for in the cfg file, the detected speed is less<br>
&gt; than 1 Gb/s, or an interface detects a different speed than what is<br>
&gt; expected from the cfg file. Otherwise, it passes.<br>
<br>
So you don&#39;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 &gt; This would become highly dependent on the NIC, and it&#39;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&#39;re trying to avoid anything that would require physical changes that can&#39;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>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dts] Speed Capabilities Feature
  2020-06-24 20:01   ` Lincoln Lavoie
@ 2020-06-24 20:09     ` Thomas Monjalon
       [not found]       ` <98CBD80474FA8B44BF855DF32C47DC35C610BC@smartserver.smartshare.dk>
  0 siblings, 1 reply; 5+ messages in thread
From: Thomas Monjalon @ 2020-06-24 20:09 UTC (permalink / raw)
  To: Lincoln Lavoie
  Cc: Daniel Kirichok, dts, dev, David Marchand, Ferruh Yigit,
	arybchenko, mb, i.dyukov, rasland, James Hendergart

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?



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dts] Speed Capabilities Feature
       [not found]       ` <98CBD80474FA8B44BF855DF32C47DC35C610BC@smartserver.smartshare.dk>
@ 2020-06-25 20:04         ` Daniel Kirichok
  0 siblings, 0 replies; 5+ messages in thread
From: Daniel Kirichok @ 2020-06-25 20:04 UTC (permalink / raw)
  To: Morten Brørup
  Cc: Thomas Monjalon, Lincoln Lavoie, dts, dev, David Marchand,
	Ferruh Yigit, arybchenko, i.dyukov, rasland, James Hendergart

[-- Attachment #1: Type: text/plain, Size: 5239 bytes --]

On Thu, Jun 25, 2020 at 3:52 AM Morten Brørup <mb@smartsharesystems.com>
wrote:

> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > Sent: Wednesday, June 24, 2020 10:09 PM
> >
> > 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
> > > >
>
> Great! The physical layer rarely gets attention by DPDK, although it is
> the foundation of everything.
>
> > > 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 agree. Otherwise we are depending on the kernel NIC driver development
> being ahead of the DPDK driver development.
>
> > I was just trying to understand why ethtool came in the picture.
>
> I guess Lincoln is referring to some "ethtool" DPDK application, right?
>
>
Dan >  After doing some rethinking, I intend to use a tool with similar
functionality to ethtool that is offered through the DPDK application.

>
> > > > > 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.
>
> As I understand it, this test verifies that the speed capabilities
> reported by DPDK matches the expectations for that driver, where the
> expectations are in the cfg file. This is good.
>
> There is no need to require any minimum speed. DPDK should be allowed to
> support 10/100 Mbps Ethernet devices.
>
>
Dan > Thanks for the clarification, I will incorporate this into the test.

> > >
> > > > 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?
> >
> >
>
> Tests to verify that the link actually comes up at the expected speeds
> would be nice too:
>
> Verify that 10/100/1000 Mbps copper Ethernet devices link up at the speed
> advertised by the tester using auto-negotiation, and at 10 and 100 Mbps
> half duplex when the tester doesn't provide auto-negotiation ("Parallel
> Detect" in IEEE 802.3 terminology). And similarly when the DUT sets the
> advertised capabilities.
>

Dan > We were thinking to cover this through checking the config file
depending on what the NIC is capable which could be multiple speeds, and
the speed it is currently linked at which would be one speed.


> Flow Control behavior should also be verified. If both tester and DUT
> advertise Flow Control, the driver should use Flow Control, and if tester
> and/or DUT advertises No Flow Control, the driver should not use flow
> control.
>
>
Dan > We were thinking to incorporate Flow Control behavior verification in
a separate test case than this one since it would need to be confirmed that
flow control is supported by the hardware before verifying for it.

I don't have a lot of experience with multi-speed modules above 1 Gbps, but
> guess similar tests apply here.
>
> And I agree that the tests should be limited to what can be automated with
> the tester. Running around pulling cables and swapping modules is not an
> option.
>
>
>

-- 

Dan Kirichok

UNH InterOperability Laboratory

21 Madbury Rd, Suite 100, Durham, NH 03824

dkirichok@iol.unh.edu

www.iol.unh.edu

[-- Attachment #2: Type: text/html, Size: 9230 bytes --]

<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 25, 2020 at 3:52 AM Morten Brørup &lt;<a href="mailto:mb@smartsharesystems.com" target="_blank">mb@smartsharesystems.com</a>&gt; 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">&gt; From: Thomas Monjalon [mailto:<a href="mailto:thomas@monjalon.net" target="_blank">thomas@monjalon.net</a>]<br>
&gt; Sent: Wednesday, June 24, 2020 10:09 PM<br>
&gt; <br>
&gt; 24/06/2020 22:01, Lincoln Lavoie:<br>
&gt; &gt; Inline.<br>
&gt; &gt;<br>
&gt; &gt; On Wed, Jun 24, 2020 at 3:55 PM Thomas Monjalon &lt;<a href="mailto:thomas@monjalon.net" target="_blank">thomas@monjalon.net</a>&gt;<br>
&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; &gt; Hi,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; A bit of context: Daniel is going to implement a test in DTS<br>
&gt; &gt; &gt; for ethdev speed capability:<br>
&gt; &gt; &gt; <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>
&gt; &gt; &gt;<br>
<br>
Great! The physical layer rarely gets attention by DPDK, although it is the foundation of everything. <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; &gt; &gt; 24/06/2020 21:32, Daniel Kirichok:<br>
&gt; &gt; &gt; &gt; The Speed Capabilities test will first check the speed of each<br>
&gt; interface<br>
&gt; &gt; &gt; &gt; that the device lists through ethtool.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I assume you mean doing a query in Linux before starting DPDK.<br>
&gt; &gt;<br>
&gt; &gt; LYL &gt; I hadn&#39;t thought about that approach, we were thinking we would<br>
&gt; &gt; compare what the tested reports as the physical reality of the setup<br>
&gt; with<br>
&gt; &gt; what the DPDK driver reports.<br>
&gt; &gt; If you think we can trust the native kernel drivers as the source of<br>
&gt; truth,<br>
&gt; &gt; we could read those first and compare DPDK output.<br>
&gt; <br>
&gt; Not sure we can trust kernel infos, especially for new HW.<br>
<br>
I agree. Otherwise we are depending on the kernel NIC driver development being ahead of the DPDK driver development.<br>
<br>
&gt; I was just trying to understand why ethtool came in the picture.<br>
<br>
I guess Lincoln is referring to some &quot;ethtool&quot; DPDK application, right?<br>
<br></blockquote><div> </div><div>Dan &gt;  After doing some rethinking, I intend to use a tool with similar functionality to ethtool that is offered through the DPDK application. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; <br>
&gt; &gt; &gt; &gt; Then it compares each interface<br>
&gt; &gt; &gt; &gt; speed to a user-defined set of expected speeds set in a newly<br>
&gt; created<br>
&gt; &gt; &gt; &gt; config file, `speed_capabilities.cfg`.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Why do you need such config file?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; The test fails if an interface is<br>
&gt; &gt; &gt; &gt; found that isn’t accounted for in the cfg file, the detected<br>
&gt; speed is<br>
&gt; &gt; &gt; less<br>
&gt; &gt; &gt; &gt; than 1 Gb/s, or an interface detects a different speed than what<br>
&gt; is<br>
&gt; &gt; &gt; &gt; expected from the cfg file. Otherwise, it passes.<br>
<br>
As I understand it, this test verifies that the speed capabilities reported by DPDK matches the expectations for that driver, where the expectations are in the cfg file. This is good.<br>
<br>
There is no need to require any minimum speed. DPDK should be allowed to support 10/100 Mbps Ethernet devices.<br>
<br></blockquote><div> </div><div>Dan &gt; Thanks for the clarification, I will incorporate this into the test. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; &gt; &gt;<br>
&gt; &gt; &gt; So you don&#39;t test DPDK?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Would be interesting to compare the actual link speed<br>
&gt; &gt; &gt; from rte_eth_link_get() with the advertised capability.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; What else do we want to test regarding link speed? autonegotiation?<br>
&gt; &gt; &gt;<br>
&gt; &gt; LYL &gt; This would become highly dependent on the NIC, and it&#39;s<br>
&gt; &gt; capabilities.  I have not had good luck with auto-neg on high speed<br>
&gt; links<br>
&gt; &gt; like 10G SPF and higher. Similarly, high speed links would likely<br>
&gt; &gt; require a physical change (assuming the NIC supported multiple<br>
&gt; speeds), to<br>
&gt; &gt; change either the module or the DAC.  We&#39;re trying to avoid anything<br>
&gt; that<br>
&gt; &gt; would require physical changes that can&#39;t be forced through<br>
&gt; &gt; the tester (i.e. disable the port connected to the DUT for a link<br>
&gt; down,<br>
&gt; &gt; etc.)<br>
&gt; <br>
&gt; At least, we can test that autonegotiation is establishing<br>
&gt; a speed advertised in capabilities, right?<br>
&gt; <br>
&gt; <br>
<br>
Tests to verify that the link actually comes up at the expected speeds would be nice too:<br>
<br>
Verify that 10/100/1000 Mbps copper Ethernet devices link up at the speed advertised by the tester using auto-negotiation, and at 10 and 100 Mbps half duplex when the tester doesn&#39;t provide auto-negotiation (&quot;Parallel Detect&quot; in IEEE 802.3 terminology). And similarly when the DUT sets the advertised capabilities.<br></blockquote><div><br></div><div>Dan &gt; We were thinking to cover this through checking the config file depending on what the NIC is capable which could be multiple speeds, and the speed it is currently linked at which would be one speed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Flow Control behavior should also be verified. If both tester and DUT advertise Flow Control, the driver should use Flow Control, and if tester and/or DUT advertises No Flow Control, the driver should not use flow control.<br>
<br></blockquote><div><br></div><div>Dan &gt; We were thinking to incorporate Flow Control behavior verification in a separate test case than this one since it would need to be confirmed that flow control is supported by the hardware before verifying for it. 

  </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I don&#39;t have a lot of experience with multi-speed modules above 1 Gbps, but guess similar tests apply here.<br>
<br>
And I agree that the tests should be limited to what can be automated with the tester. Running around pulling cables and swapping modules is not an option.<br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><span><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Dan Kirichok </span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">UNH InterOperability Laboratory</span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">21 Madbury Rd, Suite 100, Durham, NH 03824</span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;font-family:Arial;color:rgb(17,85,204);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><a href="mailto:dkirichok@iol.unh.edu" target="_blank">dkirichok@iol.unh.edu</a></span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><a href="http://www.iol.unh.edu/" style="background-color:transparent;font-family:Arial;font-size:10pt;white-space:pre-wrap" target="_blank">www.iol.unh.edu</a><br></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><br></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;font-family:Arial;color:rgb(51,51,51);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><img src="https://lh4.googleusercontent.com/PiGr1LaEiC-EkbE7843LHDkVaXFGXwW1Yq2aTfjqzd4i2Qg4CTl2icsDGzMw7dKAZpsr-ofI7V45PIFuH3dmnEy-TXRMf5i10fUBwx-NxZUtk1aCK48Y-UX9L5qDtl1YkMb1Wl0" width="150" height="37" style="border:none"></span></p><div><span style="font-size:10pt;font-family:Arial;color:rgb(51,51,51);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><br></span></div></span></div></div></div>

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-24 19:32 [dts] Speed Capabilities Feature Daniel Kirichok
2020-06-24 19:55 ` Thomas Monjalon
2020-06-24 20:01   ` Lincoln Lavoie
2020-06-24 20:09     ` Thomas Monjalon
     [not found]       ` <98CBD80474FA8B44BF855DF32C47DC35C610BC@smartserver.smartshare.dk>
2020-06-25 20:04         ` Daniel Kirichok

test suite reviews and discussions

Archives are clonable:
	git clone --mirror http://inbox.dpdk.org/dts/0 dts/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dts dts/ http://inbox.dpdk.org/dts \
		dts@dpdk.org
	public-inbox-index dts


Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dts


AGPL code for this site: git clone https://public-inbox.org/ public-inbox