Re: Doubts in JumboFrames and stats_checks tests in DTS.

[Patrick Robb <probb@iol.unh.edu>]

[-- 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 --]