[RFC,v2] Initial Implementation For Jumbo Frames Test Suite
Checks
Commit Message
The following test suite reflects the fundamental outline for how the
jumbo frames test suite may be designed. The test suite consists of five
individual test cases, each of which assesses the behavior of packet
transmissions for both 1518 byte and 9000 byte frames.
The edge cases are ripped directly from the old DTS framework, and the
general methodology is the same as well. The process, at this point, has
been refactored to operate within the new DTS framework.
Bugzilla ID: 1421
Signed-off-by: Nicholas Pratte <npratte@iol.unh.edu>
---
dts/framework/config/conf_yaml_schema.json | 3 +-
dts/tests/TestSuite_jumboframes.py | 182 +++++++++++++++++++++
2 files changed, 184 insertions(+), 1 deletion(-)
create mode 100644 dts/tests/TestSuite_jumboframes.py
Comments
On Fri, 21 Jun 2024 17:19:21 -0400
Nicholas Pratte <npratte@iol.unh.edu> wrote:
> +The test suite ensures the consistency of jumbo frames transmission within
> +Poll Mode Drivers using a series of individual test cases. If a Poll Mode
> +Driver receives a packet that is greater than its assigned MTU length, then
> +that packet will be dropped, and thus not received. Likewise, if a Poll Mode Driver
> +receives a packet that is less than or equal to a its designated MTU length, then the
> +packet should be transmitted by the Poll Mode Driver, completing a cycle within the
> +testbed and getting received by the traffic generator. Thus, the following test suite
> +evaluates the behavior within all possible edge cases, ensuring that a test Poll
> +Mode Driver strictly abides by the above implications.
There are some weird drivers where MRU and MTU are not the same thing.
I believe the e1000 HW only allowed setting buffer size to a power of 2.
At least on Linux, that meant that with 1500 byte MTU it would receive an up to 2K packet.
This never caused any problem for upper layer protocols, just some picky conformance tests.
> On Jun 21, 2024, at 5:18 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
>
> On Fri, 21 Jun 2024 17:19:21 -0400
> Nicholas Pratte <npratte@iol.unh.edu> wrote:
>
>> +The test suite ensures the consistency of jumbo frames transmission within
>> +Poll Mode Drivers using a series of individual test cases. If a Poll Mode
>> +Driver receives a packet that is greater than its assigned MTU length, then
>> +that packet will be dropped, and thus not received. Likewise, if a Poll Mode Driver
>> +receives a packet that is less than or equal to a its designated MTU length, then the
>> +packet should be transmitted by the Poll Mode Driver, completing a cycle within the
>> +testbed and getting received by the traffic generator. Thus, the following test suite
>> +evaluates the behavior within all possible edge cases, ensuring that a test Poll
>> +Mode Driver strictly abides by the above implications.
>
> There are some weird drivers where MRU and MTU are not the same thing.
> I believe the e1000 HW only allowed setting buffer size to a power of 2.
> At least on Linux, that meant that with 1500 byte MTU it would receive an up to 2K packet.
> This never caused any problem for upper layer protocols, just some picky conformance tests.
The test cases should not concern themselves with individual PMD behaviors. They should be based on the API definition.
The previous comments led me to go on an investigation about how MTUs
are allocated in testpmd. --max-pkt-len, which the documentation
states is defaulted to 1518, will shave off 18 bytes to account for
the 14 byte Ethernet frame and the Dot1Q headers. This is the case
when using Mellanox, but for both Intel and Broadcom, when explicitly
setting --max-pkt-len to 1518, the MTU listed on 'show port info' is
1492. So there are 26 bytes being shaved off, leaving 8 unknown bytes.
Does anyone know what these extra 8 bytes are? I wondered if these
might be VXLAN, FCS or something else, but it might just be easier to
ask and see if anyone knows; I can't find anything about it in
documentation.
As far as how this relates to the test suite at hand, the
send_packet_and_capture() method will need to be reworked to
compensate for the extra 4 Dot1Q header bytes, but I'm still curious
about the extra 8 bytes on the Intel and Broadcom devices I've tested
on; again, these bytes are not present on Mellanox, which is just
bound to their specific kernel drivers. When I manually set the
--max-pkt-len to 1518, with the MTU then set to 1492 bytes, packets
sent to the SUT can only be, including frame size, 1514 bytes in size.
So I'm looking at the DPDK MTU output plus 22, even when using 'port
config mtu 0 1500,' for instance, so I'm not sure why 26 bytes is
subtracted here.
On Fri, Jun 21, 2024 at 7:55 PM Honnappa Nagarahalli
<Honnappa.Nagarahalli@arm.com> wrote:
>
>
>
> > On Jun 21, 2024, at 5:18 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
> >
> > On Fri, 21 Jun 2024 17:19:21 -0400
> > Nicholas Pratte <npratte@iol.unh.edu> wrote:
> >
> >> +The test suite ensures the consistency of jumbo frames transmission within
> >> +Poll Mode Drivers using a series of individual test cases. If a Poll Mode
> >> +Driver receives a packet that is greater than its assigned MTU length, then
> >> +that packet will be dropped, and thus not received. Likewise, if a Poll Mode Driver
> >> +receives a packet that is less than or equal to a its designated MTU length, then the
> >> +packet should be transmitted by the Poll Mode Driver, completing a cycle within the
> >> +testbed and getting received by the traffic generator. Thus, the following test suite
> >> +evaluates the behavior within all possible edge cases, ensuring that a test Poll
> >> +Mode Driver strictly abides by the above implications.
> >
> > There are some weird drivers where MRU and MTU are not the same thing.
> > I believe the e1000 HW only allowed setting buffer size to a power of 2.
> > At least on Linux, that meant that with 1500 byte MTU it would receive an up to 2K packet.
> > This never caused any problem for upper layer protocols, just some picky conformance tests.
> The test cases should not concern themselves with individual PMD behaviors. They should be based on the API definition.
>
Nicholas, you are writing a test for the API.
You should not adapt to the driver behaviour.
If the driver does not report what we can expect from the API definition,
it is a bug.
Ferruh, please can you explain what is the problem with MTU sizes?
25/06/2024 21:57, Nicholas Pratte:
> The previous comments led me to go on an investigation about how MTUs
> are allocated in testpmd. --max-pkt-len, which the documentation
> states is defaulted to 1518, will shave off 18 bytes to account for
> the 14 byte Ethernet frame and the Dot1Q headers. This is the case
> when using Mellanox, but for both Intel and Broadcom, when explicitly
> setting --max-pkt-len to 1518, the MTU listed on 'show port info' is
> 1492. So there are 26 bytes being shaved off, leaving 8 unknown bytes.
> Does anyone know what these extra 8 bytes are? I wondered if these
> might be VXLAN, FCS or something else, but it might just be easier to
> ask and see if anyone knows; I can't find anything about it in
> documentation.
>
> As far as how this relates to the test suite at hand, the
> send_packet_and_capture() method will need to be reworked to
> compensate for the extra 4 Dot1Q header bytes, but I'm still curious
> about the extra 8 bytes on the Intel and Broadcom devices I've tested
> on; again, these bytes are not present on Mellanox, which is just
> bound to their specific kernel drivers. When I manually set the
> --max-pkt-len to 1518, with the MTU then set to 1492 bytes, packets
> sent to the SUT can only be, including frame size, 1514 bytes in size.
> So I'm looking at the DPDK MTU output plus 22, even when using 'port
> config mtu 0 1500,' for instance, so I'm not sure why 26 bytes is
> subtracted here.
>
> On Fri, Jun 21, 2024 at 7:55 PM Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com> wrote:
> >
> >
> >
> > > On Jun 21, 2024, at 5:18 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
> > >
> > > On Fri, 21 Jun 2024 17:19:21 -0400
> > > Nicholas Pratte <npratte@iol.unh.edu> wrote:
> > >
> > >> +The test suite ensures the consistency of jumbo frames transmission within
> > >> +Poll Mode Drivers using a series of individual test cases. If a Poll Mode
> > >> +Driver receives a packet that is greater than its assigned MTU length, then
> > >> +that packet will be dropped, and thus not received. Likewise, if a Poll Mode Driver
> > >> +receives a packet that is less than or equal to a its designated MTU length, then the
> > >> +packet should be transmitted by the Poll Mode Driver, completing a cycle within the
> > >> +testbed and getting received by the traffic generator. Thus, the following test suite
> > >> +evaluates the behavior within all possible edge cases, ensuring that a test Poll
> > >> +Mode Driver strictly abides by the above implications.
> > >
> > > There are some weird drivers where MRU and MTU are not the same thing.
> > > I believe the e1000 HW only allowed setting buffer size to a power of 2.
> > > At least on Linux, that meant that with 1500 byte MTU it would receive an up to 2K packet.
> > > This never caused any problem for upper layer protocols, just some picky conformance tests.
> > The test cases should not concern themselves with individual PMD behaviors. They should be based on the API definition.
> >
>
On Tue, 25 Jun 2024 15:57:02 -0400
Nicholas Pratte <npratte@iol.unh.edu> wrote:
> The previous comments led me to go on an investigation about how MTUs
> are allocated in testpmd. --max-pkt-len, which the documentation
> states is defaulted to 1518, will shave off 18 bytes to account for
> the 14 byte Ethernet frame and the Dot1Q headers. This is the case
> when using Mellanox, but for both Intel and Broadcom, when explicitly
> setting --max-pkt-len to 1518, the MTU listed on 'show port info' is
> 1492. So there are 26 bytes being shaved off, leaving 8 unknown bytes.
> Does anyone know what these extra 8 bytes are? I wondered if these
> might be VXLAN, FCS or something else, but it might just be easier to
> ask and see if anyone knows; I can't find anything about it in
> documentation.
>
> As far as how this relates to the test suite at hand, the
> send_packet_and_capture() method will need to be reworked to
> compensate for the extra 4 Dot1Q header bytes, but I'm still curious
> about the extra 8 bytes on the Intel and Broadcom devices I've tested
> on; again, these bytes are not present on Mellanox, which is just
> bound to their specific kernel drivers. When I manually set the
> --max-pkt-len to 1518, with the MTU then set to 1492 bytes, packets
> sent to the SUT can only be, including frame size, 1514 bytes in size.
> So I'm looking at the DPDK MTU output plus 22, even when using 'port
> config mtu 0 1500,' for instance, so I'm not sure why 26 bytes is
> subtracted here.
>
> On Fri, Jun 21, 2024 at 7:55 PM Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com> wrote:
> >
> >
> >
> > > On Jun 21, 2024, at 5:18 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
> > >
> > > On Fri, 21 Jun 2024 17:19:21 -0400
> > > Nicholas Pratte <npratte@iol.unh.edu> wrote:
> > >
> > >> +The test suite ensures the consistency of jumbo frames transmission within
> > >> +Poll Mode Drivers using a series of individual test cases. If a Poll Mode
> > >> +Driver receives a packet that is greater than its assigned MTU length, then
> > >> +that packet will be dropped, and thus not received. Likewise, if a Poll Mode Driver
> > >> +receives a packet that is less than or equal to a its designated MTU length, then the
> > >> +packet should be transmitted by the Poll Mode Driver, completing a cycle within the
> > >> +testbed and getting received by the traffic generator. Thus, the following test suite
> > >> +evaluates the behavior within all possible edge cases, ensuring that a test Poll
> > >> +Mode Driver strictly abides by the above implications.
> > >
> > > There are some weird drivers where MRU and MTU are not the same thing.
> > > I believe the e1000 HW only allowed setting buffer size to a power of 2.
> > > At least on Linux, that meant that with 1500 byte MTU it would receive an up to 2K packet.
> > > This never caused any problem for upper layer protocols, just some picky conformance tests.
> > The test cases should not concern themselves with individual PMD behaviors. They should be based on the API definition.
> >
There is confusion in DPDK about Maximum Transmission Unit (MTU) vs Maximum Receive Unit (MRU).
For almost all things, they are the same thing, but technically there is a difference.
https://swamy2064.wordpress.com/2018/12/01/mtu-and-mru/
If I would like to create a test suite that is driver agnostic, then I
would need to increase the boundaries at which I conduct each
individual test case. Right now, I test jumbo frame behavior -1, +1,
or at the MTU boundary. But, packets in TestPMD are dropped or
forwarded based on the MTU size plus additional ethernet overhead. We
would need to agree on a universal expected value for ethernet
overhead across all devices, or come up with another solution.
I created a Bugzilla ticket to discuss this further, it might make
sense to discuss this outside of this thread.
https://bugs.dpdk.org/show_bug.cgi?id=1476
On Tue, Jun 25, 2024 at 5:57 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> Nicholas, you are writing a test for the API.
> You should not adapt to the driver behaviour.
> If the driver does not report what we can expect from the API definition,
> it is a bug.
>
> Ferruh, please can you explain what is the problem with MTU sizes?
>
>
> 25/06/2024 21:57, Nicholas Pratte:
> > The previous comments led me to go on an investigation about how MTUs
> > are allocated in testpmd. --max-pkt-len, which the documentation
> > states is defaulted to 1518, will shave off 18 bytes to account for
> > the 14 byte Ethernet frame and the Dot1Q headers. This is the case
> > when using Mellanox, but for both Intel and Broadcom, when explicitly
> > setting --max-pkt-len to 1518, the MTU listed on 'show port info' is
> > 1492. So there are 26 bytes being shaved off, leaving 8 unknown bytes.
> > Does anyone know what these extra 8 bytes are? I wondered if these
> > might be VXLAN, FCS or something else, but it might just be easier to
> > ask and see if anyone knows; I can't find anything about it in
> > documentation.
> >
> > As far as how this relates to the test suite at hand, the
> > send_packet_and_capture() method will need to be reworked to
> > compensate for the extra 4 Dot1Q header bytes, but I'm still curious
> > about the extra 8 bytes on the Intel and Broadcom devices I've tested
> > on; again, these bytes are not present on Mellanox, which is just
> > bound to their specific kernel drivers. When I manually set the
> > --max-pkt-len to 1518, with the MTU then set to 1492 bytes, packets
> > sent to the SUT can only be, including frame size, 1514 bytes in size.
> > So I'm looking at the DPDK MTU output plus 22, even when using 'port
> > config mtu 0 1500,' for instance, so I'm not sure why 26 bytes is
> > subtracted here.
> >
> > On Fri, Jun 21, 2024 at 7:55 PM Honnappa Nagarahalli
> > <Honnappa.Nagarahalli@arm.com> wrote:
> > >
> > >
> > >
> > > > On Jun 21, 2024, at 5:18 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
> > > >
> > > > On Fri, 21 Jun 2024 17:19:21 -0400
> > > > Nicholas Pratte <npratte@iol.unh.edu> wrote:
> > > >
> > > >> +The test suite ensures the consistency of jumbo frames transmission within
> > > >> +Poll Mode Drivers using a series of individual test cases. If a Poll Mode
> > > >> +Driver receives a packet that is greater than its assigned MTU length, then
> > > >> +that packet will be dropped, and thus not received. Likewise, if a Poll Mode Driver
> > > >> +receives a packet that is less than or equal to a its designated MTU length, then the
> > > >> +packet should be transmitted by the Poll Mode Driver, completing a cycle within the
> > > >> +testbed and getting received by the traffic generator. Thus, the following test suite
> > > >> +evaluates the behavior within all possible edge cases, ensuring that a test Poll
> > > >> +Mode Driver strictly abides by the above implications.
> > > >
> > > > There are some weird drivers where MRU and MTU are not the same thing.
> > > > I believe the e1000 HW only allowed setting buffer size to a power of 2.
> > > > At least on Linux, that meant that with 1500 byte MTU it would receive an up to 2K packet.
> > > > This never caused any problem for upper layer protocols, just some picky conformance tests.
> > > The test cases should not concern themselves with individual PMD behaviors. They should be based on the API definition.
> > >
> >
>
>
>
>
>
@@ -187,7 +187,8 @@
"enum": [
"hello_world",
"os_udp",
- "pmd_buffer_scatter"
+ "pmd_buffer_scatter",
+ "jumboframes"
]
},
"test_target": {
new file mode 100644
@@ -0,0 +1,182 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2023-2024 University of New Hampshire
+"""Jumbo frame consistency and compatibility test suite.
+
+The test suite ensures the consistency of jumbo frames transmission within
+Poll Mode Drivers using a series of individual test cases. If a Poll Mode
+Driver receives a packet that is greater than its assigned MTU length, then
+that packet will be dropped, and thus not received. Likewise, if a Poll Mode Driver
+receives a packet that is less than or equal to a its designated MTU length, then the
+packet should be transmitted by the Poll Mode Driver, completing a cycle within the
+testbed and getting received by the traffic generator. Thus, the following test suite
+evaluates the behavior within all possible edge cases, ensuring that a test Poll
+Mode Driver strictly abides by the above implications.
+"""
+
+from time import sleep
+
+from scapy.layers.inet import IP # type: ignore[import-untyped]
+from scapy.layers.l2 import Ether # type: ignore[import-untyped]
+from scapy.packet import Raw # type: ignore[import-untyped]
+
+from framework.remote_session.testpmd_shell import TestPmdShell
+from framework.test_suite import TestSuite
+
+ETHER_HEADER_LEN = 18
+IP_HEADER_LEN = 20
+ETHER_STANDARD_MTU = 1518
+ETHER_JUMBO_FRAME_MTU = 9000
+
+
+class TestJumboframes(TestSuite):
+ """DPDK PMD jumbo frames test suite.
+
+ Asserts the expected behavior of frames greater than, less then, or equal to
+ a designated MTU size in the testpmd application. If a packet size greater
+ than the designated testpmd MTU length is retrieved, the test fails. If a
+ packet size less than or equal to the designated testpmd MTU length is retrieved,
+ the test passes.
+ """
+
+ def set_up_suite(self) -> None:
+ """Set up the test suite.
+
+ Setup:
+ Set traffic generator MTU lengths to a size greater than scope of all
+ test cases.
+ """
+ self.tg_node.main_session.configure_port_mtu(
+ ETHER_JUMBO_FRAME_MTU + 200, self._tg_port_egress
+ )
+ self.tg_node.main_session.configure_port_mtu(
+ ETHER_JUMBO_FRAME_MTU + 200, self._tg_port_ingress
+ )
+
+ def send_packet_and_verify(self, pktsize: int, should_receive: bool = True) -> None:
+ """Generate, send, and capture packets to verify that the sent packet was received or not.
+
+ Generates a packet based on a specified size and sends it to the SUT. The desired packet's
+ payload size is calculated, and arbitrary, byte-sized characters are inserted into the
+ packet before sending. Packets are captured, and depending on the test case, packet
+ payloads are checked to determine if the sent payload was received.
+
+ Args:
+ pktsize: Size of packet to be generated and sent.
+ should_receive: Indicate whether the test case expects to receive the packet or not.
+ """
+ pktlength = pktsize - ETHER_HEADER_LEN
+ padding = pktlength - IP_HEADER_LEN
+
+ packet = Ether() / IP(len=pktlength) / Raw(load="\x50" * padding)
+ received_packets = self.send_packet_and_capture(packet)
+
+ found = any(
+ ("\x50" * padding) in str(packets.load)
+ for packets in received_packets
+ if hasattr(packets, "load")
+ )
+
+ print(found)
+ if should_receive:
+ self.verify(found, "Packet pass assert error")
+ else:
+ self.verify(not found, "Packet drop assert error")
+
+ def test_jumboframes_normal_nojumbo(self) -> None:
+ """Assess the boundaries of packets sent less than or equal to the standard MTU length.
+
+ PMDs are set to the standard MTU length of 1518 to assess behavior of sent packets less than
+ or equal to this size. Sends two packets: one that is less than 1518 bytes, and another that
+ is equal to 1518 bytes. The test case expects to receive both packets.
+
+ Test:
+ Start testpmd and send packets of sizes 1517 and 1518.
+ """
+ testpmd = TestPmdShell(self.sut_node, max_pkt_len=ETHER_STANDARD_MTU, tx_offloads=0x8000)
+ testpmd.start()
+ self.send_packet_and_verify(ETHER_STANDARD_MTU - 1)
+ self.send_packet_and_verify(ETHER_STANDARD_MTU)
+ testpmd.close()
+ sleep(6)
+
+ def test_jumboframes_jumbo_nojumbo(self) -> None:
+ """Assess the boundaries of packets sent greater than standard MTU length.
+
+ PMDs are set to the standard MTU length of 1518 bytes to assess behavior of sent packets
+ greater than this size. Sends one packet with a frame size of 1519. The test cases does
+ not expect to receive this packet.
+
+ Test:
+ Start testpmd with standard MTU size of 1518. Send a packet of 1519 and verify it was
+ not received.
+ """
+ testpmd = TestPmdShell(self.sut_node, max_pkt_len=ETHER_STANDARD_MTU, tx_offloads=0x8000)
+ testpmd.start()
+ self.send_packet_and_verify(ETHER_STANDARD_MTU + 1, False)
+ testpmd.close()
+ sleep(6)
+
+ def test_jumboframes_normal_jumbo(self) -> None:
+ """Assess the consistency of standard 1518 byte packets using a 9000 byte jumbo MTU length.
+
+ PMDs are set to a jumbo frame size of 9000 bytes. Packets of sizes 1517 and 1518 are sent
+ to assess the boundaries of packets less than or equal to the standard MTU length of 1518.
+ The test case expects to receive both packets.
+
+ Test:
+ Start testpmd with a jumbo frame size of 9000 bytes. Send a packet of 1517 and 1518
+ and verify they were received.
+ """
+ testpmd = TestPmdShell(self.sut_node, max_pkt_len=ETHER_JUMBO_FRAME_MTU, tx_offloads=0x8000)
+ testpmd.start()
+ self.send_packet_and_verify(ETHER_STANDARD_MTU - 1)
+ self.send_packet_and_verify(ETHER_STANDARD_MTU)
+ testpmd.close()
+ sleep(6)
+
+ def test_jumboframes_jumbo_jumbo(self) -> None:
+ """Assess the boundaries packets sent at an MTU size of 9000 bytes.
+
+ PMDs are set to a jumbo frames size of 9000 bytes. Packets of size 1519, 8999, and 9000
+ are sent. The test expects to receive all packets.
+
+ Test:
+ Start testpmd with an MTU length of 9000 bytes. Send packets of size 1519, 8999,
+ and 9000 and verify that all packets were received.
+ """
+ testpmd = TestPmdShell(self.sut_node, max_pkt_len=ETHER_JUMBO_FRAME_MTU, tx_offloads=0x8000)
+ testpmd.start()
+ self.send_packet_and_verify(ETHER_STANDARD_MTU + 1)
+ self.send_packet_and_verify(ETHER_JUMBO_FRAME_MTU - 1)
+ self.send_packet_and_verify(ETHER_JUMBO_FRAME_MTU)
+ testpmd.close()
+ sleep(6)
+
+ def test_jumboframes_bigger_jumbo(self) -> None:
+ """Assess the behavior of packets send greater than a specified MTU length of 9000 bytes.
+
+ PMDs are set to a jumbo frames size of 9000 bytes. A packet of size 9001 is sent to the SUT.
+ The test case does not expect to receive the packet.
+
+ Test:
+ Start testpmd with an MTU length of 9000 bytes. Send a packet of 9001 bytes and verify
+ it was not received.
+ """
+ testpmd = TestPmdShell(self.sut_node, max_pkt_len=ETHER_JUMBO_FRAME_MTU, tx_offloads=0x8000)
+ testpmd.start()
+ self.send_packet_and_verify(ETHER_JUMBO_FRAME_MTU + 1, False)
+ testpmd.close()
+ sleep(6)
+
+ def tear_down_suite(self) -> None:
+ """Tear down the test suite.
+
+ Teardown:
+ Set the MTU size of the traffic generator back to the standard 1518 byte size.
+ """
+ self.tg_node.main_session.configure_port_mtu(
+ ETHER_STANDARD_MTU - ETHER_HEADER_LEN, self._tg_port_egress
+ )
+ self.tg_node.main_session.configure_port_mtu(
+ ETHER_STANDARD_MTU - ETHER_HEADER_LEN, self._tg_port_ingress
+ )