Re: Doubts in JumboFrames and stats_checks tests in DTS.

Re: Doubts in JumboFrames and stats_checks tests in DTS.

[Patrick Robb]

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

Hi Bharati,

Welcome to the DTS mailing list. I will try to provide some answers based
on my experience running DTS at the DPDK Community Lab at UNH. I will also
flag that this "legacy" version of DTS is deprecated and getting minimal
maintenance. The majority of the current efforts for DTS are directed
towards the rewrite which exists within the /dts dir of the DPDK repo:
https://git.dpdk.org/dpdk/tree/dts

With that being said, of course the legacy repo is still useful and I
encourage you to use it, so I will provide some comments inline below:

On Fri, Nov 22, 2024 at 9:43 AM Bharati Bhole - Geminus <
c_bharatib@xsightlabs.com> wrote:

> Hi,
>
> I am Bharati Bhole. I am a new member of DTS mailing list.
> I have recently started working on DTS for my company and facing some
> issues/failures while running the DTS.
> Please help me with understanding the test cases and expected behaviours.
>
> I am trying to understand the DTS behaviour for following TCs:
>
> 1. JumboFrames :
>
>    1. When the test set the max_pkt_len for testpmd and calculate the
>    expected acceptable packet size, does it consider NICs supporting 2 VLANS?
>    (In case of MTU update test, I have seen that 2 VLANs NIC are being
>    considered while calculating acceptable packets size but in JumboFrames I
>    dont see it).
>
>
No, 2 VLANs is not properly accounted for in the Jumboframes testsuite.
And, this is actually highly topical, as this is an ongoing point of
discussion in rewriting jumboframes and mtu_update for the new DTS
framework (the testcases are getting combined into 1 testsuite).  I will
paste the function from mtu_update of legacy DTS which you may be referring
to:

------------------------------

    def send_packet_of_size_to_port(self, port_id: int, pktsize: int):

        # The packet total size include ethernet header, ip header, and
payload.
        # ethernet header length is 18 bytes, ip standard header length is
20 bytes.
        # pktlen = pktsize - ETHER_HEADER_LEN
        if self.kdriver in ["igb", "igc", "ixgbe"]:
            max_pktlen = pktsize + ETHER_HEADER_LEN + VLAN
            padding = max_pktlen - IP_HEADER_LEN - ETHER_HEADER_LEN - VLAN
        else:
            max_pktlen = pktsize + ETHER_HEADER_LEN + VLAN * 2
            padding = max_pktlen - IP_HEADER_LEN - ETHER_HEADER_LEN
        out = self.send_scapy_packet(
            port_id,
            f'Ether(dst=dutmac,
src="52:00:00:00:00:00")/IP()/Raw(load="\x50"*{padding})',

------------------------------

One difference between legacy DTS and the "new" DTS is that in legacy DTS a
master list of devices/drivers was maintained, and there were an endless
amount of conditions like this where a device list would be checked, and
then some behavior modified based on that list. Because this strategy leads
to bugs, it's unresponsive to changes in driver code, hard to maintain, and
for other reasons, we are no longer follow this approach in new DTS. Now,
if we want to toggle different behavior (like determine max_pkt_len for a
given MTU for a given device) that needs to be accomplished by querying
testpmd for device info (there are various testpmd runtime commands for
this). And, in situations where testpmd doesn't expose the information we
need for checking device behavior in a particular testsuite - testpmd needs
to be updated to allow for this.

I am CC'ing Nick who is the person writing the new jumboframes + MTU
testsuite, which (work in progress) is on patchwork here:
https://patchwork.dpdk.org/project/dpdk/patch/20240726141307.14410-3-npratte@iol.unh.edu/

Nick, maybe you can include the mailing list threads Thomas linke you, and
explain your current understanding of how to handle this issue? This won't
really help Bharati in the short term, but at least it will clarify to him
how this issue will be handled in the new DTS framework, which presumably
he will upgrade to using at some point.


>    1.
>    2. In function jumboframes_send_packet() -
>    --<snip>--
>    if received:
>               * if self.nic.startswith("fastlinq"):*
>                    self.verify(
>                        self.pmdout.check_tx_bytes(tx_pkts, rx_pkts)
>                        and (self.pmdout.check_tx_bytes(tx_bytes, pktsize))
>                        and (rx_bytes == pktsize),
>                        "packet pass assert error",
>                    )
>               * else:*
>                    self.verify(
>                        self.pmdout.check_tx_bytes(tx_pkts, rx_pkts)
>                        and (self.pmdout.check_tx_bytes(tx_bytes *+ 4*,
>    pktsize))
>                        and ((rx_bytes *+ 4*) == pktsize),
>                        "packet pass assert error",
>                    )
>            else:
>                self.verify(rx_err == 1 or tx_pkts == 0, "packet drop
>    assert error")
>            return out
>    --<snip>--
>
> Can someone please tell me why these tx_butes and rx_bytes calculations
> are different for Qlogic NICs and other NICs?
>

I don't know the reason why fastlinq has this behavior in DPDK, so I'm
CCing the dev mailing list - maybe someone there will have the historical
knowledge to answer.

Otherwise, in terms of DTS, this is again an example of a workflow which we
do not allow in new DTS.


>
>
>    3.
>
> 2. TestSuite_stats_checks.py :
> The test, test_stats_checks is sending 2 packets of ETH/IP/RAW(30) and
> ETH/IP/RAW(1500).
>
> In function send_packet_of_size_to_tx_port()  line no. 174 to 185
> --<snip>--
>
> if received:
>             self.verify(tx_pkts_difference >= 1, "No packet was sent")
>             self.verify(
>                 tx_pkts_difference == rx_pkts_difference,
>                 "different numbers of packets sent and received",
>             )
>             self.verify(
>                 tx_bytes_difference == rx_bytes_difference,
>                 "different number of bytes sent and received",
>             )
>             self.verify(*tx_err_difference* == 1, "unexpected tx error")
>             self.verify(*rx_err_difference *== 0, "unexpected rx error")
>
> --<snip>--
>
> This test expects packets with payload size 30 to pass RX and TX which is
> working fine and for packet with payload size 1500, the test expecting RX
> and to pass and TX to fail?
> I did not get this part. The defailt MTU size is 1500. When scapy sends
> the packet with ETH+IP+1500 the packet size is 18+20+1500 = 1538. And even
> if the NIC supports 2 VLAN the max it can accept is MTU+ETH+CRC+2*VLAN =
> 1526
> So according the to my understanding the packets should be dropped and
> rx_error counter should increase and there should not be any increment in
> good/error packet for TX port.
>

This is not a testsuite that we run at our lab but I have read through the
testplan and test file. I think your math makes sense and I would expect
that rx_err_difference would be 1 in this scenario. When we rework this
testsuite, obviously we will need to start testpmd with various NICs, send
packets with RAW(1500) and see if port stats shows rx_err 1 or 0. I am
curious to see if this is the universal behavior in DPDK, or just some
unique behavior from Intel 700 series (legacy DTS was often written towards
the behavior of this device). A goal in rewriting our tests is ensuring
that DPDK apis (which we reach through testpmd) truly return the same
behavior across different NICs.

Sorry about the half answer. Maybe someone else from the dev mailing list
can provide a response about how this RAW(1500) packet can be received on
rx port on any DPDK device.

I can say that we do have this stats_checks testsuite marked as a candidate
to rewrite for new DTS in this current development cycle (DPDK 25.03).
Maybe we can loop you into these conversations, since you have an interest
in the subject? And, there's no pressure on this, but I will just add you
to the invite list for the DPDK DTS meetings (meets once every 2 weeks) in
case you want to join and discuss.


>
> Can someone please tell what is the gap/missing part in my understanding?
>
> Thanks,
> Bharati Bhole.
>
>
Thanks for getting involved - I'm glad to see more companies making use of
DTS.

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

Re: Doubts in JumboFrames and stats_checks tests in DTS.

[Patrick Robb]

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

Hi Bharati,

It might be easiest to address your questions over a video conference call
instead of email. Would this be okay?

I am free tomorrow 11/26 16:00-18:00 UTC, or Wednesday 11/27 14:00-16:00
UTC and 20:00-22:00 UTC. Or I have other availability if none of these work.

On Mon, Nov 25, 2024 at 5:45 AM Bharati Bhole - Geminus <
c_bharatib@xsightlabs.com> wrote:

> Hi Patrik,
>
> I used site - https://dpdk.org/git/dpdk to clone the DPDK code. I tried
> to go through the DTS/README.md file.
>
> This file says, it uses docker container for dev as well as test
> execution. But I did not find any steps for setting up the test environment
> for it.
>
> I tried to look for the steps at
> https://doc.dpdk.org/guides/tools/dts.html but its not there.
> Can you please point me to the document for the execution steps?
>
> Thanks,
> Bharati.
>
> ------------------------------
> *From:* Patrick Robb <probb@iol.unh.edu>
> *Sent:* 22 November 2024 10:29 PM
> *To:* Bharati Bhole - Geminus <c_bharatib@xsightlabs.com>
> *Cc:* dts@dpdk.org <dts@dpdk.org>; Nicholas Pratte <npratte@iol.unh.edu>;
> Dean Marx <dmarx@iol.unh.edu>; Paul Szczepanek <Paul.Szczepanek@arm.com>;
> Luca Vizzarro <Luca.Vizzarro@arm.com>; NBU-Contact-Thomas Monjalon
> (EXTERNAL) <thomas@monjalon.net>; dev <dev@dpdk.org>
> *Subject:* Re: Doubts in JumboFrames and stats_checks tests in DTS.
>
> Hi Bharati,
>
> Welcome to the DTS mailing list. I will try to provide some answers based
> on my experience running DTS at the DPDK Community Lab at UNH. I will also
> flag that this "legacy" version of DTS is deprecated and getting minimal
> maintenance. The majority of the current efforts for DTS are directed
> towards the rewrite which exists within the /dts dir of the DPDK repo:
> https://git.dpdk.org/dpdk/tree/dts
>
> With that being said, of course the legacy repo is still useful and I
> encourage you to use it, so I will provide some comments inline below:
>
> On Fri, Nov 22, 2024 at 9:43 AM Bharati Bhole - Geminus <
> c_bharatib@xsightlabs.com> wrote:
>
> Hi,
>
> I am Bharati Bhole. I am a new member of DTS mailing list.
> I have recently started working on DTS for my company and facing some
> issues/failures while running the DTS.
> Please help me with understanding the test cases and expected behaviours.
>
> I am trying to understand the DTS behaviour for following TCs:
>
> 1. JumboFrames :
>
>    1. When the test set the max_pkt_len for testpmd and calculate the
>    expected acceptable packet size, does it consider NICs supporting 2 VLANS?
>    (In case of MTU update test, I have seen that 2 VLANs NIC are being
>    considered while calculating acceptable packets size but in JumboFrames I
>    dont see it).
>
>
> No, 2 VLANs is not properly accounted for in the Jumboframes testsuite.
> And, this is actually highly topical, as this is an ongoing point of
> discussion in rewriting jumboframes and mtu_update for the new DTS
> framework (the testcases are getting combined into 1 testsuite).  I will
> paste the function from mtu_update of legacy DTS which you may be referring
> to:
>
> ------------------------------
>
>     def send_packet_of_size_to_port(self, port_id: int, pktsize: int):
>
>         # The packet total size include ethernet header, ip header, and
> payload.
>         # ethernet header length is 18 bytes, ip standard header length is
> 20 bytes.
>         # pktlen = pktsize - ETHER_HEADER_LEN
>         if self.kdriver in ["igb", "igc", "ixgbe"]:
>             max_pktlen = pktsize + ETHER_HEADER_LEN + VLAN
>             padding = max_pktlen - IP_HEADER_LEN - ETHER_HEADER_LEN - VLAN
>         else:
>             max_pktlen = pktsize + ETHER_HEADER_LEN + VLAN * 2
>             padding = max_pktlen - IP_HEADER_LEN - ETHER_HEADER_LEN
>         out = self.send_scapy_packet(
>             port_id,
>             f'Ether(dst=dutmac,
> src="52:00:00:00:00:00")/IP()/Raw(load="\x50"*{padding})',
>
> ------------------------------
>
> One difference between legacy DTS and the "new" DTS is that in legacy DTS
> a master list of devices/drivers was maintained, and there were an endless
> amount of conditions like this where a device list would be checked, and
> then some behavior modified based on that list. Because this strategy leads
> to bugs, it's unresponsive to changes in driver code, hard to maintain, and
> for other reasons, we are no longer follow this approach in new DTS. Now,
> if we want to toggle different behavior (like determine max_pkt_len for a
> given MTU for a given device) that needs to be accomplished by querying
> testpmd for device info (there are various testpmd runtime commands for
> this). And, in situations where testpmd doesn't expose the information we
> need for checking device behavior in a particular testsuite - testpmd needs
> to be updated to allow for this.
>
> I am CC'ing Nick who is the person writing the new jumboframes + MTU
> testsuite, which (work in progress) is on patchwork here:
> https://patchwork.dpdk.org/project/dpdk/patch/20240726141307.14410-3-npratte@iol.unh.edu/
>
> Nick, maybe you can include the mailing list threads Thomas linke you, and
> explain your current understanding of how to handle this issue? This won't
> really help Bharati in the short term, but at least it will clarify to him
> how this issue will be handled in the new DTS framework, which presumably
> he will upgrade to using at some point.
>
>
>    1.
>    2. In function jumboframes_send_packet() -
>    --<snip>--
>    if received:
>               * if self.nic.startswith("fastlinq"):*
>                    self.verify(
>                        self.pmdout.check_tx_bytes(tx_pkts, rx_pkts)
>                        and (self.pmdout.check_tx_bytes(tx_bytes, pktsize))
>                        and (rx_bytes == pktsize),
>                        "packet pass assert error",
>                    )
>               * else:*
>                    self.verify(
>                        self.pmdout.check_tx_bytes(tx_pkts, rx_pkts)
>                        and (self.pmdout.check_tx_bytes(tx_bytes *+ 4*,
>    pktsize))
>                        and ((rx_bytes *+ 4*) == pktsize),
>                        "packet pass assert error",
>                    )
>            else:
>                self.verify(rx_err == 1 or tx_pkts == 0, "packet drop
>    assert error")
>            return out
>    --<snip>--
>
> Can someone please tell me why these tx_butes and rx_bytes calculations
> are different for Qlogic NICs and other NICs?
>
>
> I don't know the reason why fastlinq has this behavior in DPDK, so I'm
> CCing the dev mailing list - maybe someone there will have the historical
> knowledge to answer.
>
> Otherwise, in terms of DTS, this is again an example of a workflow which
> we do not allow in new DTS.
>
>
>
>
>    3.
>
> 2. TestSuite_stats_checks.py :
> The test, test_stats_checks is sending 2 packets of ETH/IP/RAW(30) and
> ETH/IP/RAW(1500).
>
> In function send_packet_of_size_to_tx_port()  line no. 174 to 185
> --<snip>--
>
> if received:
>             self.verify(tx_pkts_difference >= 1, "No packet was sent")
>             self.verify(
>                 tx_pkts_difference == rx_pkts_difference,
>                 "different numbers of packets sent and received",
>             )
>             self.verify(
>                 tx_bytes_difference == rx_bytes_difference,
>                 "different number of bytes sent and received",
>             )
>             self.verify(*tx_err_difference* == 1, "unexpected tx error")
>             self.verify(*rx_err_difference *== 0, "unexpected rx error")
>
> --<snip>--
>
> This test expects packets with payload size 30 to pass RX and TX which is
> working fine and for packet with payload size 1500, the test expecting RX
> and to pass and TX to fail?
> I did not get this part. The defailt MTU size is 1500. When scapy sends
> the packet with ETH+IP+1500 the packet size is 18+20+1500 = 1538. And even
> if the NIC supports 2 VLAN the max it can accept is MTU+ETH+CRC+2*VLAN =
> 1526
> So according the to my understanding the packets should be dropped and
> rx_error counter should increase and there should not be any increment in
> good/error packet for TX port.
>
>
> This is not a testsuite that we run at our lab but I have read through the
> testplan and test file. I think your math makes sense and I would expect
> that rx_err_difference would be 1 in this scenario. When we rework this
> testsuite, obviously we will need to start testpmd with various NICs, send
> packets with RAW(1500) and see if port stats shows rx_err 1 or 0. I am
> curious to see if this is the universal behavior in DPDK, or just some
> unique behavior from Intel 700 series (legacy DTS was often written towards
> the behavior of this device). A goal in rewriting our tests is ensuring
> that DPDK apis (which we reach through testpmd) truly return the same
> behavior across different NICs.
>
> Sorry about the half answer. Maybe someone else from the dev mailing list
> can provide a response about how this RAW(1500) packet can be received on
> rx port on any DPDK device.
>
> I can say that we do have this stats_checks testsuite marked as a
> candidate to rewrite for new DTS in this current development cycle (DPDK
> 25.03). Maybe we can loop you into these conversations, since you have an
> interest in the subject? And, there's no pressure on this, but I will just
> add you to the invite list for the DPDK DTS meetings (meets once every 2
> weeks) in case you want to join and discuss.
>
>
>
> Can someone please tell what is the gap/missing part in my understanding?
>
> Thanks,
> Bharati Bhole.
>
>
> Thanks for getting involved - I'm glad to see more companies making use of
> DTS.
>

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

Re: Doubts in JumboFrames and stats_checks tests in DTS.

[Patrick Robb]

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

Hi Bharati,

Thanks, here is the meeting info. I'll see you tomorrow!

---------------------------

Patrick Robb is inviting you to a scheduled Zoom meeting.

Topic: Bharati & Patrick DTS Discussion
Time: Nov 26, 2024 11:00 AM Eastern Time (US and Canada)

Join from PC, Mac, Linux, iOS or Android: https://unh.zoom.us/j/92634291594

Keyboard shortcuts are available to navigate this Zoom meeting or webinar:
https://support.zoom.us/hc/en-us/articles/205683899-Hot-Keys-and-Keyboard-for-Zoom

Or iPhone one-tap:  13017158592,92634291594# or 13052241968,92634291594#

Or Telephone:
    Dial: +1 301 715 8592 (US Toll)
    Meeting ID: 926 3429 1594
    International numbers available: https://unh.zoom.us/u/aHJatyofh

Or a H.323/SIP room system:
    H.323: rc.unh.edu or 162.255.37.11 (US West) or 162.255.36.11 (US East)
    Meeting ID: 926 3429 1594
    SIP: 92634291594@zoomcrc.com

TROUBLESHOOTING STEPS:

Audio Echo In A Meeting:
https://support.zoom.us/hc/en-us/articles/202050538-Audio-Echo-In-A-Meeting

Want to Join a Test Meeting?: https://zoom.us/test

On Mon, Nov 25, 2024 at 12:37 PM Bharati Bhole - Geminus <
c_bharatib@xsightlabs.com> wrote:

> Hi Patrick,
>
> 11/26 16:00 UTC works for me.
> Please let me know which link to join.
>
> Thanks,
> Bharati.
> ------------------------------
> *From:* Patrick Robb <probb@iol.unh.edu>
> *Sent:* Monday, November 25, 2024 9:27:29 PM
> *To:* Bharati Bhole - Geminus <c_bharatib@xsightlabs.com>
> *Cc:* dts@dpdk.org <dts@dpdk.org>; Nicholas Pratte <npratte@iol.unh.edu>;
> Dean Marx <dmarx@iol.unh.edu>; Paul Szczepanek <Paul.Szczepanek@arm.com>;
> Luca Vizzarro <Luca.Vizzarro@arm.com>; NBU-Contact-Thomas Monjalon
> (EXTERNAL) <thomas@monjalon.net>; dev <dev@dpdk.org>
> *Subject:* Re: Doubts in JumboFrames and stats_checks tests in DTS.
>
> Hi Bharati,
>
> It might be easiest to address your questions over a video conference call
> instead of email. Would this be okay?
>
> I am free tomorrow 11/26 16:00-18:00 UTC, or Wednesday 11/27 14:00-16:00
> UTC and 20:00-22:00 UTC. Or I have other availability if none of these work.
>
> On Mon, Nov 25, 2024 at 5:45 AM Bharati Bhole - Geminus <
> c_bharatib@xsightlabs.com> wrote:
>
> Hi Patrik,
>
> I used site - https://dpdk.org/git/dpdk to clone the DPDK code. I tried
> to go through the DTS/README.md file.
>
> This file says, it uses docker container for dev as well as test
> execution. But I did not find any steps for setting up the test environment
> for it.
>
> I tried to look for the steps at
> https://doc.dpdk.org/guides/tools/dts.html but its not there.
> Can you please point me to the document for the execution steps?
>
> Thanks,
> Bharati.
>
> ------------------------------
> *From:* Patrick Robb <probb@iol.unh.edu>
> *Sent:* 22 November 2024 10:29 PM
> *To:* Bharati Bhole - Geminus <c_bharatib@xsightlabs.com>
> *Cc:* dts@dpdk.org <dts@dpdk.org>; Nicholas Pratte <npratte@iol.unh.edu>;
> Dean Marx <dmarx@iol.unh.edu>; Paul Szczepanek <Paul.Szczepanek@arm.com>;
> Luca Vizzarro <Luca.Vizzarro@arm.com>; NBU-Contact-Thomas Monjalon
> (EXTERNAL) <thomas@monjalon.net>; dev <dev@dpdk.org>
> *Subject:* Re: Doubts in JumboFrames and stats_checks tests in DTS.
>
> Hi Bharati,
>
> Welcome to the DTS mailing list. I will try to provide some answers based
> on my experience running DTS at the DPDK Community Lab at UNH. I will also
> flag that this "legacy" version of DTS is deprecated and getting minimal
> maintenance. The majority of the current efforts for DTS are directed
> towards the rewrite which exists within the /dts dir of the DPDK repo:
> https://git.dpdk.org/dpdk/tree/dts
>
> With that being said, of course the legacy repo is still useful and I
> encourage you to use it, so I will provide some comments inline below:
>
> On Fri, Nov 22, 2024 at 9:43 AM Bharati Bhole - Geminus <
> c_bharatib@xsightlabs.com> wrote:
>
> Hi,
>
> I am Bharati Bhole. I am a new member of DTS mailing list.
> I have recently started working on DTS for my company and facing some
> issues/failures while running the DTS.
> Please help me with understanding the test cases and expected behaviours.
>
> I am trying to understand the DTS behaviour for following TCs:
>
> 1. JumboFrames :
>
>    1. When the test set the max_pkt_len for testpmd and calculate the
>    expected acceptable packet size, does it consider NICs supporting 2 VLANS?
>    (In case of MTU update test, I have seen that 2 VLANs NIC are being
>    considered while calculating acceptable packets size but in JumboFrames I
>    dont see it).
>
>
> No, 2 VLANs is not properly accounted for in the Jumboframes testsuite.
> And, this is actually highly topical, as this is an ongoing point of
> discussion in rewriting jumboframes and mtu_update for the new DTS
> framework (the testcases are getting combined into 1 testsuite).  I will
> paste the function from mtu_update of legacy DTS which you may be referring
> to:
>
> ------------------------------
>
>     def send_packet_of_size_to_port(self, port_id: int, pktsize: int):
>
>         # The packet total size include ethernet header, ip header, and
> payload.
>         # ethernet header length is 18 bytes, ip standard header length is
> 20 bytes.
>         # pktlen = pktsize - ETHER_HEADER_LEN
>         if self.kdriver in ["igb", "igc", "ixgbe"]:
>             max_pktlen = pktsize + ETHER_HEADER_LEN + VLAN
>             padding = max_pktlen - IP_HEADER_LEN - ETHER_HEADER_LEN - VLAN
>         else:
>             max_pktlen = pktsize + ETHER_HEADER_LEN + VLAN * 2
>             padding = max_pktlen - IP_HEADER_LEN - ETHER_HEADER_LEN
>         out = self.send_scapy_packet(
>             port_id,
>             f'Ether(dst=dutmac,
> src="52:00:00:00:00:00")/IP()/Raw(load="\x50"*{padding})',
>
> ------------------------------
>
> One difference between legacy DTS and the "new" DTS is that in legacy DTS
> a master list of devices/drivers was maintained, and there were an endless
> amount of conditions like this where a device list would be checked, and
> then some behavior modified based on that list. Because this strategy leads
> to bugs, it's unresponsive to changes in driver code, hard to maintain, and
> for other reasons, we are no longer follow this approach in new DTS. Now,
> if we want to toggle different behavior (like determine max_pkt_len for a
> given MTU for a given device) that needs to be accomplished by querying
> testpmd for device info (there are various testpmd runtime commands for
> this). And, in situations where testpmd doesn't expose the information we
> need for checking device behavior in a particular testsuite - testpmd needs
> to be updated to allow for this.
>
> I am CC'ing Nick who is the person writing the new jumboframes + MTU
> testsuite, which (work in progress) is on patchwork here:
> https://patchwork.dpdk.org/project/dpdk/patch/20240726141307.14410-3-npratte@iol.unh.edu/
>
> Nick, maybe you can include the mailing list threads Thomas linke you, and
> explain your current understanding of how to handle this issue? This won't
> really help Bharati in the short term, but at least it will clarify to him
> how this issue will be handled in the new DTS framework, which presumably
> he will upgrade to using at some point.
>
>
>    1.
>    2. In function jumboframes_send_packet() -
>    --<snip>--
>    if received:
>               * if self.nic.startswith("fastlinq"):*
>                    self.verify(
>                        self.pmdout.check_tx_bytes(tx_pkts, rx_pkts)
>                        and (self.pmdout.check_tx_bytes(tx_bytes, pktsize))
>                        and (rx_bytes == pktsize),
>                        "packet pass assert error",
>                    )
>               * else:*
>                    self.verify(
>                        self.pmdout.check_tx_bytes(tx_pkts, rx_pkts)
>                        and (self.pmdout.check_tx_bytes(tx_bytes *+ 4*,
>    pktsize))
>                        and ((rx_bytes *+ 4*) == pktsize),
>                        "packet pass assert error",
>                    )
>            else:
>                self.verify(rx_err == 1 or tx_pkts == 0, "packet drop
>    assert error")
>            return out
>    --<snip>--
>
> Can someone please tell me why these tx_butes and rx_bytes calculations
> are different for Qlogic NICs and other NICs?
>
>
> I don't know the reason why fastlinq has this behavior in DPDK, so I'm
> CCing the dev mailing list - maybe someone there will have the historical
> knowledge to answer.
>
> Otherwise, in terms of DTS, this is again an example of a workflow which
> we do not allow in new DTS.
>
>
>
>
>    3.
>
> 2. TestSuite_stats_checks.py :
> The test, test_stats_checks is sending 2 packets of ETH/IP/RAW(30) and
> ETH/IP/RAW(1500).
>
> In function send_packet_of_size_to_tx_port()  line no. 174 to 185
> --<snip>--
>
> if received:
>             self.verify(tx_pkts_difference >= 1, "No packet was sent")
>             self.verify(
>                 tx_pkts_difference == rx_pkts_difference,
>                 "different numbers of packets sent and received",
>             )
>             self.verify(
>                 tx_bytes_difference == rx_bytes_difference,
>                 "different number of bytes sent and received",
>             )
>             self.verify(*tx_err_difference* == 1, "unexpected tx error")
>             self.verify(*rx_err_difference *== 0, "unexpected rx error")
>
> --<snip>--
>
> This test expects packets with payload size 30 to pass RX and TX which is
> working fine and for packet with payload size 1500, the test expecting RX
> and to pass and TX to fail?
> I did not get this part. The defailt MTU size is 1500. When scapy sends
> the packet with ETH+IP+1500 the packet size is 18+20+1500 = 1538. And even
> if the NIC supports 2 VLAN the max it can accept is MTU+ETH+CRC+2*VLAN =
> 1526
> So according the to my understanding the packets should be dropped and
> rx_error counter should increase and there should not be any increment in
> good/error packet for TX port.
>
>
> This is not a testsuite that we run at our lab but I have read through the
> testplan and test file. I think your math makes sense and I would expect
> that rx_err_difference would be 1 in this scenario. When we rework this
> testsuite, obviously we will need to start testpmd with various NICs, send
> packets with RAW(1500) and see if port stats shows rx_err 1 or 0. I am
> curious to see if this is the universal behavior in DPDK, or just some
> unique behavior from Intel 700 series (legacy DTS was often written towards
> the behavior of this device). A goal in rewriting our tests is ensuring
> that DPDK apis (which we reach through testpmd) truly return the same
> behavior across different NICs.
>
> Sorry about the half answer. Maybe someone else from the dev mailing list
> can provide a response about how this RAW(1500) packet can be received on
> rx port on any DPDK device.
>
> I can say that we do have this stats_checks testsuite marked as a
> candidate to rewrite for new DTS in this current development cycle (DPDK
> 25.03). Maybe we can loop you into these conversations, since you have an
> interest in the subject? And, there's no pressure on this, but I will just
> add you to the invite list for the DPDK DTS meetings (meets once every 2
> weeks) in case you want to join and discuss.
>
>
>
> Can someone please tell what is the gap/missing part in my understanding?
>
> Thanks,
> Bharati Bhole.
>
>
> Thanks for getting involved - I'm glad to see more companies making use of
> DTS.
>
>

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