From: Bharati Bhole - Geminus <c_bharatib@xsightlabs.com>
To: "dts@dpdk.org" <dts@dpdk.org>
Subject: Doubts in JumboFrames and stats_checks tests in DTS.
Date: Fri, 22 Nov 2024 14:42:50 +0000 [thread overview]
Message-ID: <AS8P193MB1605C8F07614F6CC11DD01EF8B232@AS8P193MB1605.EURP193.PROD.OUTLOOK.COM> (raw)
[-- Attachment #1: Type: text/plain, Size: 3267 bytes --]
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).
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?
1.
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.
Can someone please tell what is the gap/missing part in my understanding?
Thanks,
Bharati Bhole.
[-- Attachment #2: Type: text/html, Size: 15661 bytes --]
next reply other threads:[~2024-11-22 14:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-22 14:42 Bharati Bhole - Geminus [this message]
2024-11-22 16:59 ` Patrick Robb
2024-11-22 17:37 ` Bharati Bhole - Geminus
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=AS8P193MB1605C8F07614F6CC11DD01EF8B232@AS8P193MB1605.EURP193.PROD.OUTLOOK.COM \
--to=c_bharatib@xsightlabs.com \
--cc=dts@dpdk.org \
/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).