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 3CC3E45D7D; Fri, 22 Nov 2024 18:01:24 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4ADE4433F7; Fri, 22 Nov 2024 18:01:23 +0100 (CET) Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) by mails.dpdk.org (Postfix) with ESMTP id A39E0433F7 for ; Fri, 22 Nov 2024 18:01:21 +0100 (CET) Received: by mail-pf1-f175.google.com with SMTP id d2e1a72fcca58-71e681bc315so1686632b3a.0 for ; Fri, 22 Nov 2024 09:01:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1732294881; x=1732899681; 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=hRwVrSmfdJ+HXT+FJGikhoE4m1RCiuUOwjH0y1VVIqo=; b=fShRdj5rB6ETfxMUSoI/NiolJ7ZMPvK5mv/GuVEJvKk7ms8PgO0KNYAJpikeMpB/4m TGyvWHbqsmDNFQCEzc4J+xiVIUuHqyfMtQGPZzYoB/kMKGzqVSf4mQZxdwR7BSEy1ldq DEZi/M4q4XqHLvgcmG/eGrH68Su7IDojZm424= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732294881; x=1732899681; 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=hRwVrSmfdJ+HXT+FJGikhoE4m1RCiuUOwjH0y1VVIqo=; b=dHaHvmVB8NJoEg6XXCQIVZiegdbuBH4Zk/T+uOZsXr1pIIO+bktT1CUKFZvSgfgB/A 5VvOlcxaUSmwucLWlCN1siIkvqZtT9gMH5QekF0pEp4m6zNFPjU2VVImmsy9sGoy5vAx wBKf31oZGDXSvYcoVOLpz38IPAWMKJXkFnS0WZo//Y3AquX2AS/91f4OEEalgCotfn+o GSzMTRuS3diomDcK62JTM0GumSzPBlie1SV/sjzI5HERp7zKTXxvz/hE68duq/ZurY5w 1PyboIJXJVw9ZZEhanG7BFrrWnZ+PfBf5j3ixkE7QZu5yfjyzPnPCiJzZYe3q6j2xCah +EiA== X-Forwarded-Encrypted: i=1; AJvYcCWm2pgAzLo7tveMFVs5rL2mQvgvNWRuf8Mh0C0xsa2hvHO/4V+ykXBaoUYmZGAIEcE2iJs=@dpdk.org X-Gm-Message-State: AOJu0YwxPfiMIuQd0L1zGmkK7iXBHwNMaQm2wcTd8h7UhkHTUzlUCQEi yemSyKD5V6goPYqEU+VKKszFmpJ9LiUvwfCqDXBnSwfAinyewCVK6DnjnQZF20GJVSjOMVMGLL/ RxkGHKAwfqa47bqHRPwGBBtF+BYZvygKH6GIv8w== X-Gm-Gg: ASbGnctYr8hC+dV+lEe73amDzpIskBy8bA0eRTa7TdQuh/9Ct/+HqwR7Bk6cLbNk4B0 tly2w2p7/xZGbUNEdH1XTQLBtSvs1gTtTxv6M1HXJWtK/Wgw2FXCvf83rmmjxrPsj X-Google-Smtp-Source: AGHT+IHTTbzHB9OY6U22MV8N4S3pJGyTbR5P27ppRKhqfPpyS6lrS/EQ02/KOYQs8bQo5qRsN0CYBFyDHMBklpx7xkk= X-Received: by 2002:a05:6a00:4984:b0:724:e739:5572 with SMTP id d2e1a72fcca58-724e73957afmr2190042b3a.10.1732294880497; Fri, 22 Nov 2024 09:01:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Patrick Robb Date: Fri, 22 Nov 2024 11:59:18 -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="000000000000ffc1ba06278354e8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --000000000000ffc1ba06278354e8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=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 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 =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 - VLA= N 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 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-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 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() - > ---- > 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 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. --000000000000ffc1ba06278354e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bharati,

Welcome to the D= TS 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 &q= uot;legacy" version of DTS is deprecated and getting minimal maintenan= ce. The majority of the current efforts for DTS are directed towards the re= write which exists within 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 s= till 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 - Geminu= s <c_bharatib@xsightlabs.co= m> 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).
    2. <= /ol>

No, 2 VLANs is not properl= y 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 combin= ed into 1 testsuite).=C2=A0 I will paste the function from mtu_update of le= gacy DTS which you may be referring to:

----------= --------------------

=C2=A0 =C2=A0 def send_packet= _of_size_to_port(self, port_id: int, pktsize: int):

=C2=A0 =C2=A0 = =C2=A0 =C2=A0 # The packet total size include ethernet header, ip header, a= nd payload.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 # ethernet header length is 18 b= ytes, ip standard 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", "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 ma= x_pktlen - IP_HEADER_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 pk= tsize + ETHER_HEADER_LEN + VLAN * 2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 padding =3D max_pktlen - IP_HEADER_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"52:00:00:00:00:00")/IP()/Raw= (load=3D"\x50"*{padding})',

--------= ----------------------
=C2=A0
One difference between le= gacy 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 condit= ions 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 re= asons, 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 devic= e info (there are various testpmd runtime commands for this). And, in situa= tions 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 i= n progress) is on patchwork here: https://patchw= ork.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, bu= t 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.


  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 d= on'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, t= his is again an example of a workflow which 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 t= est file. I think your math makes sense and I would expect that rx_err_diff= erence would be 1 in this scenario. When we rework this testsuite, obviousl= y we will need to start testpmd with various NICs, send packets with RAW(15= 00) 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 devic= e). A goal in rewriting our tests is ensuring that DPDK apis (which we reac= h 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) packe= t can be received=C2=A0on rx port on any DPDK device.

<= div>I can say that we do have this stats_checks testsuite marked as a candi= date 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.
=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 i= nvolved - I'm glad to see more companies making use of DTS.=C2=A0
=
--000000000000ffc1ba06278354e8--