From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
To: Adam Hassick <ahassick@iol.unh.edu>
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: Mon, 20 Nov 2023 20:18:55 +0300 [thread overview]
Message-ID: <276e8fb3-b185-4434-aca5-4629c5ff8ad1@oktetlabs.ru> (raw)
In-Reply-To: <CAC-YWqjqOoRc51ksTGh3+yYHGYfBQWSmrs4E-ES4etDVKS3jyg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7644 bytes --]
Hi Adam,
On 11/16/23 23:03, Adam Hassick wrote:
> 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.
Thanks a lot. Hopefully fixed.
>
> 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
> <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
> <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.
Me too. Corresponding packet has source MAC from Peer/Tester machine NIC.
It is really strange since prologue disabled LLDP there as well. I'll
try to play with it locally more, but have no good ideas in fact.
> 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
> <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.
This problem is fixed in fresh TE and dpdk-ethdev-ts published on GitHub.
Regards,
Andrew.
>
> 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
> <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
> <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
> <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: 13454 bytes --]
next prev parent reply other threads:[~2023-11-20 17:19 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
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 ` Andrew Rybchenko [this message]
2023-12-01 14:39 ` Setting up DPDK PMD Test Suite 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=276e8fb3-b185-4434-aca5-4629c5ff8ad1@oktetlabs.ru \
--to=andrew.rybchenko@oktetlabs.ru \
--cc=Konstantin.Ushakov@oktetlabs.ru \
--cc=ahassick@iol.unh.edu \
--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).