From: Adam Hassick <ahassick@iol.unh.edu>
To: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Cc: Konstantin Ushakov <Konstantin.Ushakov@oktetlabs.ru>,
Patrick Robb <probb@iol.unh.edu>,
ci@dpdk.org
Subject: Re: Setting up DPDK PMD Test Suite
Date: Thu, 16 Nov 2023 15:03:35 -0500 [thread overview]
Message-ID: <CAC-YWqjqOoRc51ksTGh3+yYHGYfBQWSmrs4E-ES4etDVKS3jyg@mail.gmail.com> (raw)
In-Reply-To: <0cd6a9fb-bc39-4b69-be5d-3470e2374016@oktetlabs.ru>
[-- Attachment #1: Type: text/plain, Size: 6247 bytes --]
Hi Andrew,
If you use copy of dpdk-ethdev-ts has
> 398e272495143884274f5a53c6fe0cc16df41052, you don't need to pass --trc-tag=pci-8086-1572
> any more since corresponding changeset updates expectations to have the
> same for pci-8086-1583.
I'll try this for the next run.
Sorry, but I've failed to find what's wrong there.
That if statement works if using the traditional single-bracket
conditional, or it needs to be rewritten as "[[ -z "${test_log}" ]] || [[ !
-r "${test_log}" ]]". The latter is the change I made, but both work.
As far as I can see LLDP packets spoil testing results:
>
> https://ts-factory.io/bublik/v2/log/362398?focusId=362760&mode=treeAndinfoAndlog&experimental=true&lineNumber=1_63
>
> As far as I can see main prologue disables FW LLDP on Tester
>
> https://ts-factory.io/bublik/v2/log/362398?focusId=362400&mode=treeAndinfoAndlog&experimental=true&lineNumber=1_80
> but I guess it could be still enabled on DUT side and DPDK do not provide
> means to disable it as far as I know. I vaguely remember that Intel
> provides FW configuration tools which can do it.
> It is interesting since DPDK gets unexpected LLDP packets but may be
> packets sent by FW go via loopback and visible to PF as well.
> Other possible source of LLDP packet is a switch if NICs are connected via
> switch. If so, LLDP should be disabled on corresponding switch ports.
>
> As far as I can see fixing the problem should make results much closer.
> However, I already see some differences in behaviour which should be simply
> fixed in TRC. For example, X710 gets 9 packets less than configuration
> number of Rx descriptors, but XL710 gets 10 packets less.
I have the "disable-fw-lldp" private flag set on both of the XL710 ports on
the DUT machine. Very strange how there are still LLDP packets appearing in
there.
These systems are not connected to any switch, so maybe a service on the
DUT itself is sending them. I'm not sure how that could be happening
though, because I don't have the LLDP daemon installed on either system.
Also I see that performance tests are not run because of failed prologue:
>
> https://ts-factory.io/bublik/v2/log/362398?focusId=369564&mode=treeAndinfoAndlog&experimental=true
> I'll investigate it, but I guess the source of difference is that we
> always run tests on single interface. Just add -p0 (--cfg=iol-dts-xl710-p0)
> to your configuration name. You don't need to change ts-rigs for it since
> the suffix is handled by generic code. It simply comments the second
> instance and forces take the first interface only into account. Initially
> it was introduced to run independent tests on different ports to be able to
> share configuration, but I guess right now it has limitations for some
> packages like representors which require entire NIC.
I can try that and will see if it works.
Thanks,
Adam
On Wed, Nov 8, 2023 at 2:20 AM Andrew Rybchenko <
andrew.rybchenko@oktetlabs.ru> wrote:
> Hi Adam,
>
> On 11/7/23 23:30, Adam Hassick wrote:
>
> Hi Andrew,
>
> The runner machine was missing a dependency for one of the scripts,
> "pixz". After installing that, it appears to have worked. I can see the
> results listed on the ts-factory Bublik instance.
>
>
> If you use copy of dpdk-ethdev-ts has
> 398e272495143884274f5a53c6fe0cc16df41052, you don't need to pass --trc-tag=pci-8086-1572
> any more since corresponding changeset updates expectations to have the
> same for pci-8086-1583.
>
> In the latest revision of ts-rigs, there appears to be a syntax error at
> line 42 within the script located at
> "ts-rigs/scripts/publish_logs/prj/ts-factory/publish", within the if
> condition. I fixed it locally to get it to run.
>
>
> Sorry, but I've failed to find what's wrong there.
>
> Taking a quick look at a comparison against your most recent X710 run, it
> looks like we're NOK on around ~400 more test cases. By percentage of
> tests, we're 1% off, however, it looks like whole subsets of the test suite
> that contain low numbers of tests are failing. I wonder if this is due to
> differences between the Intel X710 and XL710 or issues in our dev testbed.
>
>
> As far as I can see LLDP packets spoil testing results:
>
> https://ts-factory.io/bublik/v2/log/362398?focusId=362760&mode=treeAndinfoAndlog&experimental=true&lineNumber=1_63
>
> As far as I can see main prologue disables FW LLDP on Tester
>
> https://ts-factory.io/bublik/v2/log/362398?focusId=362400&mode=treeAndinfoAndlog&experimental=true&lineNumber=1_80
> but I guess it could be still enabled on DUT side and DPDK do not provide
> means to disable it as far as I know. I vaguely remember that Intel
> provides FW configuration tools which can do it.
> It is interesting since DPDK gets unexpected LLDP packets but may be
> packets sent by FW go via loopback and visible to PF as well.
> Other possible source of LLDP packet is a switch if NICs are connected via
> switch. If so, LLDP should be disabled on corresponding switch ports.
>
> As far as I can see fixing the problem should make results much closer.
> However, I already see some differences in behaviour which should be simply
> fixed in TRC. For example, X710 gets 9 packets less than configuration
> number of Rx descriptors, but XL710 gets 10 packets less.
>
> Also I see that performance tests are not run because of failed prologue:
>
> https://ts-factory.io/bublik/v2/log/362398?focusId=369564&mode=treeAndinfoAndlog&experimental=true
> I'll investigate it, but I guess the source of difference is that we
> always run tests on single interface. Just add -p0 (--cfg=iol-dts-xl710-p0)
> to your configuration name. You don't need to change ts-rigs for it since
> the suffix is handled by generic code. It simply comments the second
> instance and forces take the first interface only into account. Initially
> it was introduced to run independent tests on different ports to be able to
> share configuration, but I guess right now it has limitations for some
> packages like representors which require entire NIC.
>
> Regards,
> Andrew.
>
> Thanks,
> Adam
>
>
> (dropped history, to keep mail size small)
>
[-- Attachment #2: Type: text/html, Size: 9750 bytes --]
next prev parent reply other threads:[~2023-11-16 20:01 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAC-YWqiQfH4Rx-Et1jGHhGK9i47d0AArKy-B2P77iYbbM+Lpig@mail.gmail.com>
[not found] ` <C3B08390-DA6D-4BDC-BBD7-98561F92FE33@oktetlabs.ru>
[not found] ` <35340484-1d7e-7e5f-cad4-c965ba541397@oktetlabs.ru>
2023-08-17 17:03 ` Adam Hassick
2023-08-18 18:40 ` Andrew Rybchenko
2023-08-20 8:40 ` Andrew Rybchenko
2023-08-21 14:19 ` Adam Hassick
2023-08-23 14:45 ` Adam Hassick
2023-08-24 8:22 ` Andrew Rybchenko
2023-08-24 14:30 ` Adam Hassick
2023-08-24 18:34 ` Andrew Rybchenko
2023-08-24 20:29 ` Adam Hassick
2023-08-24 20:54 ` Andrew Rybchenko
2023-08-25 13:57 ` Andrew Rybchenko
2023-08-25 14:06 ` Adam Hassick
2023-08-25 14:41 ` Andrew Rybchenko
2023-08-25 17:35 ` Andrew Rybchenko
2023-08-28 15:02 ` Adam Hassick
2023-08-28 21:05 ` Andrew Rybchenko
2023-08-29 12:07 ` Andrew Rybchenko
2023-08-29 14:02 ` Adam Hassick
2023-08-29 20:43 ` Andrew Rybchenko
2023-08-31 19:38 ` Adam Hassick
2023-09-01 7:59 ` Andrew Rybchenko
2023-09-05 15:01 ` Adam Hassick
2023-09-06 11:36 ` Andrew Rybchenko
2023-09-06 15:00 ` Adam Hassick
2023-09-08 14:57 ` Adam Hassick
2023-09-13 15:45 ` Andrew Rybchenko
2023-09-18 6:15 ` Andrew Rybchenko
2023-09-18 6:23 ` Konstantin Ushakov
2023-09-18 6:26 ` Andrew Rybchenko
2023-09-18 14:44 ` Adam Hassick
2023-09-18 15:04 ` Andrew Rybchenko
2023-10-04 13:48 ` Adam Hassick
2023-10-05 10:25 ` Andrew Rybchenko
2023-10-10 14:09 ` Adam Hassick
2023-10-11 11:46 ` Andrew Rybchenko
2023-10-23 11:11 ` Andrew Rybchenko
2023-10-25 20:27 ` Adam Hassick
2023-10-26 12:19 ` Andrew Rybchenko
2023-10-26 17:44 ` Adam Hassick
2023-10-27 8:01 ` Andrew Rybchenko
2023-10-27 19:13 ` Andrew Rybchenko
2023-11-06 23:16 ` Adam Hassick
2023-11-07 16:57 ` Andrew Rybchenko
2023-11-07 20:30 ` Adam Hassick
2023-11-08 7:20 ` Andrew Rybchenko
2023-11-16 20:03 ` Adam Hassick [this message]
2023-11-16 20:38 ` DPDK Coverity test run Mcnamara, John
2023-11-16 20:43 ` Patrick Robb
2023-11-16 20:56 ` Mcnamara, John
2023-11-20 17:18 ` Setting up DPDK PMD Test Suite Andrew Rybchenko
2023-12-01 14:39 ` Andrew Rybchenko
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=CAC-YWqjqOoRc51ksTGh3+yYHGYfBQWSmrs4E-ES4etDVKS3jyg@mail.gmail.com \
--to=ahassick@iol.unh.edu \
--cc=Konstantin.Ushakov@oktetlabs.ru \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=ci@dpdk.org \
--cc=probb@iol.unh.edu \
/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).