From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id F175145DA5; Mon, 25 Nov 2024 16:59:36 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E15BD40A82; Mon, 25 Nov 2024 16:59:36 +0100 (CET) Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) by mails.dpdk.org (Postfix) with ESMTP id D971440265 for ; Mon, 25 Nov 2024 16:59:34 +0100 (CET) Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-7250906bc63so970026b3a.1 for ; Mon, 25 Nov 2024 07:59:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1732550374; x=1733155174; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tjNGDgzb09X+aIOTLy1rMm9nf9JueLRZ0/MzQxGYCsM=; b=h8pgzREsDloi24+JBdTdBBNo3u82VsUA4AZiWCh9irfImx3+FNcnhnwaufdYHBB285 QjdZWRvwfQb3S2JjOLZKWUrOD6jJrttzLYlsGTS/Fp8MFgrp6vAqSnCYHqKxt0HHsRsl BUnOyluw+wLg/vO//w7RhK77tggPvAHhhpGbE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732550374; x=1733155174; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tjNGDgzb09X+aIOTLy1rMm9nf9JueLRZ0/MzQxGYCsM=; b=dds5vQNqFiOZ5sW7bAE4BJv77UxiJylhX/Ur7Ayc3mERdTk7jDmayAfi+JQH7oroWY 4uMD1x2x+2C0qwqlP7ckRmzyQNMyc99T1qcNOQMcjzuNrfMr4LPpJOsYjrDx7obQ7sIj OvNRcnwQloGqBv7ujt4RD/MDxoVlrUrmA7w4GlguP4i6NcbSAhgQjcVt9XKWEcug1kvP /lUHmu9HudgVs2L0mxQpRwONT/LpGfW3cd2SwsFugN8jqGzOi5RLhlW8tlDiVYosQ7sb U7TOLQZboVijd5QxxVof0Q716LGeI/OYeEl+pUFS8ma9vkybz5Lfl+Oqc6hhlyLM8yA+ FDkA== X-Gm-Message-State: AOJu0Yz9XUSu6gN8Ie4MvXhcdSFMv5bwAsIN5Pt+CBwndmxyowd8MwrB v5c5QjGJ9zo6eKDTj799Z2ZjkyW/FSz1n/ws51qVoRnScrfr2iEISzEuOciFfyI/mzm8asn8CS9 Zt4beuIpm7E4WZ7Omq4RSoLLzUlwK8usZK0eTNQ== X-Gm-Gg: ASbGnctgdMGEJSo6vrw/Vo6XOgH7X4uJ66ykhs5iR5KNiPZluOpsYsy5EPI+p6myUU5 wUwb99UuGgR4TTHHQ9B2CHVBOXx+WJu7YV3SxBCM5po6uJ7AOVHSpVcDm3L5n/1Zj X-Google-Smtp-Source: AGHT+IHRMmRBgQsQDT50Z4ajDgKZGDfIAx3Wzp2gS/AClWmfYJ1wbqAYTF4kToBioYz+NN96FzxEIWifGz4mQ+cWcm8= X-Received: by 2002:a05:6a00:17a5:b0:724:ed54:f780 with SMTP id d2e1a72fcca58-724ed55098fmr17427338b3a.3.1732550373769; Mon, 25 Nov 2024 07:59:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Patrick Robb Date: Mon, 25 Nov 2024 10:57:29 -0500 Message-ID: Subject: Re: Doubts in JumboFrames and stats_checks tests in DTS. To: Bharati Bhole - Geminus Cc: "dts@dpdk.org" , Nicholas Pratte , Dean Marx , Paul Szczepanek , Luca Vizzarro , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , dev Content-Type: multipart/alternative; boundary="000000000000959dd90627bed180" X-BeenThere: dts@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: test suite reviews and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dts-bounces@dpdk.org --000000000000959dd90627bed180 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM 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 environme= nt > 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 > *Sent:* 22 November 2024 10:29 PM > *To:* Bharati Bhole - Geminus > *Cc:* dts@dpdk.org ; Nicholas Pratte ; > Dean Marx ; Paul Szczepanek ; > Luca Vizzarro ; NBU-Contact-Thomas Monjalon > (EXTERNAL) ; dev > *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 als= o > 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=E2=80=AFAM 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 VL= ANS? > (In case of MTU update test, I have seen that 2 VLANs NIC are being > considered while calculating acceptable packets size but in JumboFrame= s 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 referri= ng > 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 i= s > 20 bytes. > # pktlen =3D pktsize - ETHER_HEADER_LEN > if self.kdriver in ["igb", "igc", "ixgbe"]: > max_pktlen =3D pktsize + ETHER_HEADER_LEN + VLAN > padding =3D max_pktlen - IP_HEADER_LEN - ETHER_HEADER_LEN - V= LAN > else: > max_pktlen =3D pktsize + ETHER_HEADER_LEN + VLAN * 2 > padding =3D max_pktlen - IP_HEADER_LEN - ETHER_HEADER_LEN > out =3D self.send_scapy_packet( > port_id, > f'Ether(dst=3Ddutmac, > src=3D"52:00:00:00:00:00")/IP()/Raw(load=3D"\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 endles= s > amount of conditions like this where a device list would be checked, and > then some behavior modified based on that list. Because this strategy lea= ds > to bugs, it's unresponsive to changes in driver code, hard to maintain, a= nd > 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 nee= ds > 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-npra= tte@iol.unh.edu/ > > Nick, maybe you can include the mailing list threads Thomas linke you, an= d > 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 hi= m > 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() - > ---- > 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 =3D=3D 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*) =3D=3D pktsize), > "packet pass assert error", > ) > else: > self.verify(rx_err =3D=3D 1 or tx_pkts =3D=3D 0, "packet d= rop > assert error") > return out > ---- > > 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 > ---- > > if received: > self.verify(tx_pkts_difference >=3D 1, "No packet was sent") > self.verify( > tx_pkts_difference =3D=3D rx_pkts_difference, > "different numbers of packets sent and received", > ) > self.verify( > tx_bytes_difference =3D=3D rx_bytes_difference, > "different number of bytes sent and received", > ) > self.verify(*tx_err_difference* =3D=3D 1, "unexpected tx erro= r") > self.verify(*rx_err_difference *=3D=3D 0, "unexpected rx erro= r") > > ---- > > 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 =3D 1538. And e= ven > if the NIC supports 2 VLAN the max it can accept is MTU+ETH+CRC+2*VLAN = =3D > 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 th= e > 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, sen= d > 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 towar= ds > 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 jus= t > 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 o= f > DTS. > --000000000000959dd90627bed180 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bharati,

It might be easiest to addr= ess your questions over a video conference call instead of email. Would thi= s be okay?=C2=A0

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=C2=A0if none of these work.

On Mon, Nov 25, 2024 at= 5:45=E2=80=AFAM Bharati Bhole - Geminus <c_bharatib@xsightlabs.com> wrote:
Hi Patrik,

I used site - https://dpdk.org/git/dpdk=C2=A0to 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=C2=A0but its not there.
Can you please point me to the document for the execution steps?

Thanks,
Bharati.

From: = Patrick Robb <pro= bb@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&g= t;; Nicholas Pratte <npratte@iol.unh.edu>; Dean Marx <dmarx@iol.unh.edu>; Paul Szczepanek <= ;Paul.Szczepan= ek@arm.com>; Luca Vizzarro <Luca.Vizzarro@arm.com>; NBU-Contact-Thomas Mon= jalon (EXTERNAL) <thomas@monjalon.net>; dev <dev@dpdk.org>=
Subject: Re: Doubts in JumboFrames and stats_checks tests in DTS.
=C2=A0
Hi Bharati,

Welcome to the DTS mailing list. I will try to provide some answers ba= sed on my experience running DTS at the DPDK Community Lab at UNH. I will a= lso flag that this "legacy" version of DTS is deprecated and gett= ing minimal maintenance. The majority of the current efforts for DTS are directed towards the rewrite which exists with= in the /dts dir of the DPDK repo:=C2=A0https://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=E2=80=AFAM Bharati Bhole - Ge= minus <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 issue= s/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 :=C2=A0
  1. When the test set the max_pkt_len for testpmd and calculate the expect= ed acceptable packet size, does it consider NICs supporting 2 VLANS? (In ca= se of MTU update test, I have seen that 2 VLANs NIC are being considered wh= ile 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 disc= ussion in rewriting jumboframes and mtu_update for the new DTS framework (t= he testcases are getting combined into 1 testsuite).=C2=A0 I will paste the function from mtu_update of lega= cy DTS which you may be referring to:

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

=C2=A0 =C2=A0 def send_packet_of_size_to_port(self, port_id: int, pkts= ize: int):

=C2=A0 =C2=A0 =C2=A0 =C2=A0 # The packet total size include ethernet header= , ip header, and payload.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 # ethernet header length is 18 bytes, ip standa= rd header length is 20 bytes.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 # pktlen =3D pktsize - ETHER_HEADER_LEN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if self.kdriver in ["igb", "igc&= quot;, "ixgbe"]:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 max_pktlen =3D pktsize + ETHER_HE= ADER_LEN + VLAN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 padding =3D max_pktlen - IP_HEADE= R_LEN - ETHER_HEADER_LEN - VLAN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 else:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 max_pktlen =3D pktsize + ETHER_HE= ADER_LEN + VLAN * 2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 padding =3D max_pktlen - IP_HEADE= R_LEN - ETHER_HEADER_LEN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 out =3D self.send_scapy_packet(
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 port_id,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 f'Ether(dst=3Ddutmac, src=3D&= quot;52:00:00:00:00:00")/IP()/Raw(load=3D"\x50"*{padding})&#= 39;,

------------------------------
=C2=A0
One difference between legacy DTS and the "new" DTS is that = in legacy DTS a master list of devices/drivers was maintained, and there we= re an endless amount of conditions like this where a device list would be c= hecked, and then some behavior modified based on that list. Because this strategy leads to bugs, it's unresponsive t= o changes in driver code, hard to maintain, and for other reasons, we are n= o longer follow this approach in new DTS. Now, if we want to toggle differe= nt behavior (like determine max_pkt_len for a given MTU for a given device) that needs to be accomplished by query= ing 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.= =C2=A0

I am CC'ing Nick who is the person writing the new jumboframes=C2= =A0+ MTU testsuite, which (work in progress) is on patchwork here: https://patchwork.dpdk.org/project/dpdk/patch/20240726141307.14410-3-npratt= e@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 w= on't really help Bharati in the short term, but at least it will clarif= y to him how this issue will be handled in the new DTS framework, which presumably he will upgrade to using at som= e point.


  2. In function jumboframes_send_packet() -=C2=A0
    --<snip>--
    if received:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0if self.nic.startswi= th("fastlinq"):
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.verify(
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = self.pmdout.check_tx_bytes(tx_pkts, rx_pkts)
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = and (self.pmdout.check_tx_bytes(tx_bytes, pktsize))
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = and (rx_bytes =3D=3D pktsize),
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = "packet pass assert error",
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 )
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0else:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.verify(
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = self.pmdout.check_tx_bytes(tx_pkts, rx_pkts)
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = and (self.pmdout.check_tx_bytes(tx_bytes + 4, pktsize))
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = and ((rx_bytes + 4) =3D=3D pktsize),
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = "packet pass assert error",
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 )
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 else:
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.verify(rx_err =3D=3D 1 = or tx_pkts =3D=3D 0, "packet drop assert error")
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 return out
    --<snip>--
=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82Can someone please te= ll 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 his= torical knowledge to answer.

Otherwise, in terms of DTS, this is again an example of a workflow whi= ch we do not allow in new DTS.
=C2=A0


2. TestSuite_stats_checks.py :=C2=A0
=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82 The test, test_stats= _checks is sending 2 packets of ETH/IP/RAW(30) and ETH/IP/RAW(1500).=C2=A0<= br> =C2=A0 =C2=A0
=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82In function send_pack= et_of_size_to_tx_port()=C2=A0 line no. 174 to 185
=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82--<snip>--

=E2=80=82=E2=80=82if received:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.verify(tx_pkts_difference &g= t;=3D 1, "No packet was sent")
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.verify(
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tx_pkts_difference = =3D=3D rx_pkts_difference,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "different num= bers of packets sent and received",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.verify(
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tx_bytes_difference= =3D=3D rx_bytes_difference,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "different num= ber of bytes sent and received",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.verify(tx_err_difference<= /b>=C2=A0=3D=3D 1, "unexpected tx error")
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.verify(rx_err_difference = =3D=3D 0, "unexpected rx error")

=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82--<snip>--=C2= =A0
=C2=A0
=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82This test expects pac= kets with payload size 30 to pass RX and TX which is working fine and for p= acket with payload size 1500, the test expecting RX and to pass and TX to f= ail?
=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82I did not get this pa= rt. The defailt MTU size is 1500. When scapy sends the packet with ETH+IP+1= 500 the packet size is 18+20+1500 =3D 1538. And even if the NIC supports 2 = VLAN the max it can accept is MTU+ETH+CRC+2*VLAN =3D 1526
=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82So according the to m= y understanding the packets should be dropped and rx_error counter should i= ncrease and there should not be any increment in good/error packet for TX p= ort.=C2=A0

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 expe= ct 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 univers= al behavior in DPDK, or just some unique behavior from Intel 700 series (le= gacy DTS was often written towards the behavior of this device). A goal in rewriting our tests is ensuring th= at DPDK apis (which we reach through testpmd) truly return the same behavio= r across different NICs.

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

I can say that we do have this stats_checks testsuite marked as a cand= idate 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 interes= t 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 discus= s.
=C2=A0

Can someone please tell what is the gap/missing part in my understanding?
=E2=80=82=E2=80=82=E2=80=82=E2=80=82
=E2=80=82=C2=A0
Thanks,
Bharati Bhole.


Thanks for getting involved - I'm glad to see more companies makin= g use of DTS.=C2=A0
--000000000000959dd90627bed180--