DPDK patches and discussions
 help / color / mirror / Atom feed
* [RFC PATCH 0/1] Initial Implementation For Jumbo Frames
@ 2024-05-24 18:36 Nicholas Pratte
  2024-05-24 18:36 ` [RFC PATCH] Initial Implementation For Jumbo Frames Test Suite Nicholas Pratte
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Nicholas Pratte @ 2024-05-24 18:36 UTC (permalink / raw)
  To: thomas, jspewock, juraj.linkes, luca.vizzarro, yoan.picchi,
	bruce.richardson, Honnappa.Nagarahalli, probb, paul.szczepanek
  Cc: dev, Nicholas Pratte

The following is a rough design for the implementation of the jumbo
frames test suite in new DTS. The test suite uses the same
testing methodology from the test suite implementation in old
DTS. In doing so, much of the logic in this implementation has been
stripped away for the sake of maintaining an OS-agnostic design
philosopgy. Thus, there are some concerns here that need further
discussion.

All test cases behave accordingly on lab hardware. However, issues with
the testpmd shell, all of which will be fixed with the upcoming context
manager, prevent the test suite from functioning properly if all test
cases are run sequentially. Thus, for testing, each test case needs to
be run individually. So, expect issues if attempting to test.

Old DTS implements some basic logic that detects 1GB NICs, specifically
when testing jumbo frame packets greater than the specified MTU length.
This is because, according to a commit message from 2016, 1GB NICs will
automatically adjust their size to +4 bytes, meaning that when setting
an MTU of 9000, testpmd adjust the MTU size to 9004. To compensate, some
logic was inserted in the old suite to adjust packet sizes accordingly.
Given that Juraj's capabilities patch is in development, it would be
possible to set a restriction on this test suite to remove the support
of 1GB NICs, which could be determined from testpmd outputs; it could
also be possible that this problem is entirely null and void today,
essentially allowing us to forget about it.

The current implementation is not developed with both the capabilities
patch and the params patch in mind; however, the current design can and
will be refactored to do so.

Nicholas Pratte (1):
  Initial Implementation For Jumbo Frames Test Suite

 dts/framework/config/conf_yaml_schema.json |   3 +-
 dts/tests/TestSuite_jumboframes.py         | 210 +++++++++++++++++++++
 2 files changed, 212 insertions(+), 1 deletion(-)
 create mode 100644 dts/tests/TestSuite_jumboframes.py

-- 
2.44.0


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [RFC PATCH] Initial Implementation For Jumbo Frames Test Suite
  2024-05-24 18:36 [RFC PATCH 0/1] Initial Implementation For Jumbo Frames Nicholas Pratte
@ 2024-05-24 18:36 ` Nicholas Pratte
  2024-06-21 21:13 ` [RFC PATCH v2 0/1] Initial Implementation For Jumbo Frames Nicholas Pratte
  2024-06-21 21:19 ` [RFC PATCH v2] Initial Implementation For Jumbo Frames Test Suite Nicholas Pratte
  2 siblings, 0 replies; 11+ messages in thread
From: Nicholas Pratte @ 2024-05-24 18:36 UTC (permalink / raw)
  To: thomas, jspewock, juraj.linkes, luca.vizzarro, yoan.picchi,
	bruce.richardson, Honnappa.Nagarahalli, probb, paul.szczepanek
  Cc: dev, Nicholas Pratte

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         | 210 +++++++++++++++++++++
 2 files changed, 212 insertions(+), 1 deletion(-)
 create mode 100644 dts/tests/TestSuite_jumboframes.py

diff --git a/dts/framework/config/conf_yaml_schema.json b/dts/framework/config/conf_yaml_schema.json
index 4731f4511d..6b9d749022 100644
--- a/dts/framework/config/conf_yaml_schema.json
+++ b/dts/framework/config/conf_yaml_schema.json
@@ -187,7 +187,8 @@
       "enum": [
         "hello_world",
         "os_udp",
-        "pmd_buffer_scatter"
+        "pmd_buffer_scatter",
+        "jumboframes"
       ]
     },
     "test_target": {
diff --git a/dts/tests/TestSuite_jumboframes.py b/dts/tests/TestSuite_jumboframes.py
new file mode 100644
index 0000000000..dd253101aa
--- /dev/null
+++ b/dts/tests/TestSuite_jumboframes.py
@@ -0,0 +1,210 @@
+# 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, completeing 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 framework.test_suite import TestSuite
+from framework.remote_session.testpmd_shell import TestPmdShell
+
+from scapy.layers.inet import IP  # type: ignore[import]
+from scapy.layers.l2 import Ether  # type: ignore[import]
+from scapy.packet import Raw  # type: ignore[import]
+
+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 = self.sut_node.create_interactive_shell(
+            TestPmdShell,
+            app_parameters=(
+                "--max-pkt-len=%s " % (ETHER_STANDARD_MTU) + "--port-topology=paired "
+                "--tx-offloads=0x8000 "
+            ),
+            privileged=True,
+        )
+        testpmd.start()
+        self.send_packet_and_verify(ETHER_STANDARD_MTU - 1)
+        self.send_packet_and_verify(ETHER_STANDARD_MTU)
+        testpmd.close()
+
+    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 = self.sut_node.create_interactive_shell(
+            TestPmdShell,
+            app_parameters=(
+                "--max-pkt-len=%s " % (ETHER_STANDARD_MTU) + "--port-topology=paired "
+                "--tx-offloads=0x8000 "
+            ),
+            privileged=True,
+        )
+        testpmd.start()
+        self.send_packet_and_verify(ETHER_STANDARD_MTU + 1, False)
+        testpmd.close()
+
+    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 = self.sut_node.create_interactive_shell(
+            TestPmdShell,
+            app_parameters=(
+                "--max-pkt-len=%s " % (ETHER_JUMBO_FRAME_MTU) + "--port-topology=paired "
+                "--tx-offloads=0x8000 "
+            ),
+            privileged=True,
+        )
+        testpmd.start()
+        self.send_packet_and_verify(ETHER_STANDARD_MTU - 1)
+        self.send_packet_and_verify(ETHER_STANDARD_MTU)
+        testpmd.close()
+
+    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 = self.sut_node.create_interactive_shell(
+            TestPmdShell,
+            app_parameters=(
+                "--max-pkt-len=%s " % (ETHER_JUMBO_FRAME_MTU) + "--port-topology=paired "
+                "--tx-offloads=0x8000 "
+            ),
+            privileged=True,
+        )
+        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()
+
+    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 = self.sut_node.create_interactive_shell(
+            TestPmdShell,
+            app_parameters=(
+                "--max-pkt-len=%s " % (ETHER_JUMBO_FRAME_MTU) + "--port-topology=paired "
+                "--tx-offloads=0x8000 "
+            ),
+            privileged=True,
+        )
+        testpmd.start()
+        self.send_packet_and_verify(ETHER_JUMBO_FRAME_MTU + 1, False)
+        testpmd.close()
+
+    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
+        )
-- 
2.44.0


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [RFC PATCH v2 0/1] Initial Implementation For Jumbo Frames
  2024-05-24 18:36 [RFC PATCH 0/1] Initial Implementation For Jumbo Frames Nicholas Pratte
  2024-05-24 18:36 ` [RFC PATCH] Initial Implementation For Jumbo Frames Test Suite Nicholas Pratte
@ 2024-06-21 21:13 ` Nicholas Pratte
  2024-06-21 21:19 ` [RFC PATCH v2] Initial Implementation For Jumbo Frames Test Suite Nicholas Pratte
  2 siblings, 0 replies; 11+ messages in thread
From: Nicholas Pratte @ 2024-06-21 21:13 UTC (permalink / raw)
  To: paul.szczepanek, jspewock, juraj.linkes, luca.vizzarro, probb,
	dmarx, bruce.richardson, Honnappa.Nagarahalli, yoan.picchi
  Cc: dev, Nicholas Pratte

v2:
  - Suite has been refactored to include latest DPDK merge.
  - Include a 6 second timer to ensure each test case passes (This is
    just temporary placement in lieu of the context manager)


Nicholas Pratte (1):
  Initial Implementation For Jumbo Frames Test Suite

 dts/framework/config/conf_yaml_schema.json |   3 +-
 dts/tests/TestSuite_jumboframes.py         | 181 +++++++++++++++++++++
 2 files changed, 183 insertions(+), 1 deletion(-)
 create mode 100644 dts/tests/TestSuite_jumboframes.py

-- 
2.44.0


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [RFC PATCH v2] Initial Implementation For Jumbo Frames Test Suite
  2024-05-24 18:36 [RFC PATCH 0/1] Initial Implementation For Jumbo Frames Nicholas Pratte
  2024-05-24 18:36 ` [RFC PATCH] Initial Implementation For Jumbo Frames Test Suite Nicholas Pratte
  2024-06-21 21:13 ` [RFC PATCH v2 0/1] Initial Implementation For Jumbo Frames Nicholas Pratte
@ 2024-06-21 21:19 ` Nicholas Pratte
  2024-06-21 22:18   ` Stephen Hemminger
  2 siblings, 1 reply; 11+ messages in thread
From: Nicholas Pratte @ 2024-06-21 21:19 UTC (permalink / raw)
  To: juraj.linkes, dmarx, jspewock, bruce.richardson, yoan.picchi,
	paul.szczepanek, Honnappa.Nagarahalli, luca.vizzarro, probb
  Cc: dev, Nicholas Pratte

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

diff --git a/dts/framework/config/conf_yaml_schema.json b/dts/framework/config/conf_yaml_schema.json
index f02a310bb5..a1028f128b 100644
--- a/dts/framework/config/conf_yaml_schema.json
+++ b/dts/framework/config/conf_yaml_schema.json
@@ -187,7 +187,8 @@
       "enum": [
         "hello_world",
         "os_udp",
-        "pmd_buffer_scatter"
+        "pmd_buffer_scatter",
+        "jumboframes"
       ]
     },
     "test_target": {
diff --git a/dts/tests/TestSuite_jumboframes.py b/dts/tests/TestSuite_jumboframes.py
new file mode 100644
index 0000000000..f1edcb789a
--- /dev/null
+++ b/dts/tests/TestSuite_jumboframes.py
@@ -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
+        )
-- 
2.44.0


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC PATCH v2] Initial Implementation For Jumbo Frames Test Suite
  2024-06-21 21:19 ` [RFC PATCH v2] Initial Implementation For Jumbo Frames Test Suite Nicholas Pratte
@ 2024-06-21 22:18   ` Stephen Hemminger
  2024-06-21 23:54     ` Honnappa Nagarahalli
  0 siblings, 1 reply; 11+ messages in thread
From: Stephen Hemminger @ 2024-06-21 22:18 UTC (permalink / raw)
  To: Nicholas Pratte
  Cc: juraj.linkes, dmarx, jspewock, bruce.richardson, yoan.picchi,
	paul.szczepanek, Honnappa.Nagarahalli, luca.vizzarro, probb, dev

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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC PATCH v2] Initial Implementation For Jumbo Frames Test Suite
  2024-06-21 22:18   ` Stephen Hemminger
@ 2024-06-21 23:54     ` Honnappa Nagarahalli
  2024-06-25 19:57       ` Nicholas Pratte
  0 siblings, 1 reply; 11+ messages in thread
From: Honnappa Nagarahalli @ 2024-06-21 23:54 UTC (permalink / raw)
  To: Stephen Hemminger
  Cc: Nicholas Pratte, Juraj Linkeš,
	dmarx, jspewock, Richardson, Bruce, yoan.picchi, Paul Szczepanek,
	Luca Vizzarro, Patrick Robb, dev, nd



> 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.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC PATCH v2] Initial Implementation For Jumbo Frames Test Suite
  2024-06-21 23:54     ` Honnappa Nagarahalli
@ 2024-06-25 19:57       ` Nicholas Pratte
  2024-06-25 21:57         ` Thomas Monjalon
  2024-06-25 23:49         ` Stephen Hemminger
  0 siblings, 2 replies; 11+ messages in thread
From: Nicholas Pratte @ 2024-06-25 19:57 UTC (permalink / raw)
  To: Honnappa Nagarahalli
  Cc: Stephen Hemminger, Juraj Linkeš,
	dmarx, jspewock, Richardson, Bruce, yoan.picchi, Paul Szczepanek,
	Luca Vizzarro, Patrick Robb, dev, nd, thomas

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.
>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC PATCH v2] Initial Implementation For Jumbo Frames Test Suite
  2024-06-25 19:57       ` Nicholas Pratte
@ 2024-06-25 21:57         ` Thomas Monjalon
  2024-06-25 23:49         ` Stephen Hemminger
  1 sibling, 0 replies; 11+ messages in thread
From: Thomas Monjalon @ 2024-06-25 21:57 UTC (permalink / raw)
  To: Nicholas Pratte, ferruh.yigit
  Cc: Honnappa Nagarahalli, Stephen Hemminger, Juraj Linkeš,
	dmarx, jspewock, Richardson, Bruce, yoan.picchi, Paul Szczepanek,
	Luca Vizzarro, Patrick Robb, dev, nd, david.marchand

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.
> >
> 






^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC PATCH v2] Initial Implementation For Jumbo Frames Test Suite
  2024-06-25 19:57       ` Nicholas Pratte
  2024-06-25 21:57         ` Thomas Monjalon
@ 2024-06-25 23:49         ` Stephen Hemminger
  1 sibling, 0 replies; 11+ messages in thread
From: Stephen Hemminger @ 2024-06-25 23:49 UTC (permalink / raw)
  To: Nicholas Pratte
  Cc: Honnappa Nagarahalli, Juraj Linkeš,
	dmarx, jspewock, Richardson, Bruce, yoan.picchi, Paul Szczepanek,
	Luca Vizzarro, Patrick Robb, dev, nd, thomas

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/

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC PATCH 0/1] Initial Implementation For Jumbo Frames
  2024-05-24 18:06 [RFC PATCH 0/1] Initial Implementation For Jumbo Frames Nicholas Pratte
@ 2024-05-24 18:13 ` Nicholas Pratte
  0 siblings, 0 replies; 11+ messages in thread
From: Nicholas Pratte @ 2024-05-24 18:13 UTC (permalink / raw)
  To: paul.szczepanek, jspewock, luca.vizzarro, thomas, juraj.linkes,
	bruce.richardson, Honnappa.Nagarahalli, probb, yoan.picchi
  Cc: dev

This is being superseded, ignore this submission.

Thanks.

On Fri, May 24, 2024 at 2:07 PM Nicholas Pratte <npratte@iol.unh.edu> wrote:
>
> The following is a rough design for the implementation of the jumbo
> frames test suite in new DTS. The test suite uses the same
> testing methodology from the test suite implementation in old
> DTS. In doing so, much of the logic in this implementation has been
> stripped away for the sake of maintaining an OS-agnostic design
> philosopgy. Thus, there are some concerns here that need further
> discussion.
>
> All test cases behave accordingly on lab hardware. However, issues with
> the testpmd shell, all of which will be fixed with the upcoming context
> manager, prevent the test suite from functioning properly if all test
> cases are run sequentially. Thus, for testing, each test case needs to
> be run individually. So, expect issues if attempting to test.
>
> Old DTS implements some basic logic that detects 1GB NICs, specifically
> when testing jumbo frame packets greater than the specified MTU length.
> This is because, according to a commit message from 2016, 1GB NICs will
> automatically adjust their size to +4 bytes, meaning that when setting
> an MTU of 9000, testpmd adjust the MTU size to 9004. To compensate, some
> logic was inserted in the old suite to adjust packet sizes accordingly.
> Given that Juraj's capabilities patch is in development, it would be
> possible to set a restriction on this test suite to remove the support
> of 1GB NICs, which could be determined from testpmd outputs; it could
> also be possible that this problem is entirely null and void today,
> essentially allowing us to forget about it.
>
> The current implementation is not developed with both the capabilities
> patch and the params patch in mind; however, the current design can and
> will be refactored to do so.
>
> Nicholas Pratte (1):
>   Initial Implementation For Jumbo Frames Test Suite
>
>  dts/framework/config/conf_yaml_schema.json |   3 +-
>  dts/framework/test_suite.py                |   8 +
>  dts/tests/TestSuite_jumboframes.py         | 210 +++++++++++++++++++++
>  3 files changed, 220 insertions(+), 1 deletion(-)
>  create mode 100644 dts/tests/TestSuite_jumboframes.py
>
> --
> 2.44.0
>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [RFC PATCH 0/1] Initial Implementation For Jumbo Frames
@ 2024-05-24 18:06 Nicholas Pratte
  2024-05-24 18:13 ` Nicholas Pratte
  0 siblings, 1 reply; 11+ messages in thread
From: Nicholas Pratte @ 2024-05-24 18:06 UTC (permalink / raw)
  To: paul.szczepanek, jspewock, luca.vizzarro, thomas, juraj.linkes,
	bruce.richardson, Honnappa.Nagarahalli, probb, yoan.picchi
  Cc: dev, Nicholas Pratte

The following is a rough design for the implementation of the jumbo
frames test suite in new DTS. The test suite uses the same
testing methodology from the test suite implementation in old
DTS. In doing so, much of the logic in this implementation has been
stripped away for the sake of maintaining an OS-agnostic design
philosopgy. Thus, there are some concerns here that need further
discussion.

All test cases behave accordingly on lab hardware. However, issues with
the testpmd shell, all of which will be fixed with the upcoming context
manager, prevent the test suite from functioning properly if all test
cases are run sequentially. Thus, for testing, each test case needs to
be run individually. So, expect issues if attempting to test.

Old DTS implements some basic logic that detects 1GB NICs, specifically
when testing jumbo frame packets greater than the specified MTU length.
This is because, according to a commit message from 2016, 1GB NICs will
automatically adjust their size to +4 bytes, meaning that when setting
an MTU of 9000, testpmd adjust the MTU size to 9004. To compensate, some
logic was inserted in the old suite to adjust packet sizes accordingly.
Given that Juraj's capabilities patch is in development, it would be
possible to set a restriction on this test suite to remove the support
of 1GB NICs, which could be determined from testpmd outputs; it could
also be possible that this problem is entirely null and void today,
essentially allowing us to forget about it.

The current implementation is not developed with both the capabilities
patch and the params patch in mind; however, the current design can and
will be refactored to do so.

Nicholas Pratte (1):
  Initial Implementation For Jumbo Frames Test Suite

 dts/framework/config/conf_yaml_schema.json |   3 +-
 dts/framework/test_suite.py                |   8 +
 dts/tests/TestSuite_jumboframes.py         | 210 +++++++++++++++++++++
 3 files changed, 220 insertions(+), 1 deletion(-)
 create mode 100644 dts/tests/TestSuite_jumboframes.py

-- 
2.44.0


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2024-06-25 23:49 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-05-24 18:36 [RFC PATCH 0/1] Initial Implementation For Jumbo Frames Nicholas Pratte
2024-05-24 18:36 ` [RFC PATCH] Initial Implementation For Jumbo Frames Test Suite Nicholas Pratte
2024-06-21 21:13 ` [RFC PATCH v2 0/1] Initial Implementation For Jumbo Frames Nicholas Pratte
2024-06-21 21:19 ` [RFC PATCH v2] Initial Implementation For Jumbo Frames Test Suite Nicholas Pratte
2024-06-21 22:18   ` Stephen Hemminger
2024-06-21 23:54     ` Honnappa Nagarahalli
2024-06-25 19:57       ` Nicholas Pratte
2024-06-25 21:57         ` Thomas Monjalon
2024-06-25 23:49         ` Stephen Hemminger
  -- strict thread matches above, loose matches on Subject: below --
2024-05-24 18:06 [RFC PATCH 0/1] Initial Implementation For Jumbo Frames Nicholas Pratte
2024-05-24 18:13 ` Nicholas Pratte

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).