Re: [RFC PATCH v2] Initial Implementation For Jumbo Frames Test Suite
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 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 > > wrote: > > > > > > > > > > > > > On Jun 21, 2024, at 5:18 PM, Stephen Hemminger > > > > wrote: > > > > > > > > On Fri, 21 Jun 2024 17:19:21 -0400 > > > > Nicholas Pratte 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. > > > > > > > > > >
Re: [RFC PATCH v2] Initial Implementation For Jumbo Frames Test Suite
On Tue, 25 Jun 2024 15:57:02 -0400 Nicholas Pratte 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 > wrote: > > > > > > > > > On Jun 21, 2024, at 5:18 PM, Stephen Hemminger > > > wrote: > > > > > > On Fri, 21 Jun 2024 17:19:21 -0400 > > > Nicholas Pratte 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/
Re: [RFC PATCH v2] Initial Implementation For Jumbo Frames Test Suite
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 > wrote: > > > > > > > > > On Jun 21, 2024, at 5:18 PM, Stephen Hemminger > > > wrote: > > > > > > On Fri, 21 Jun 2024 17:19:21 -0400 > > > Nicholas Pratte 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. > > >
Re: [RFC PATCH v2] Initial Implementation For Jumbo Frames Test Suite
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 wrote: > > > > > On Jun 21, 2024, at 5:18 PM, Stephen Hemminger > > wrote: > > > > On Fri, 21 Jun 2024 17:19:21 -0400 > > Nicholas Pratte 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. >
Re: [RFC PATCH v2] Initial Implementation For Jumbo Frames Test Suite
> On Jun 21, 2024, at 5:18 PM, Stephen Hemminger > wrote: > > On Fri, 21 Jun 2024 17:19:21 -0400 > Nicholas Pratte 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.
Re: [RFC PATCH v2] Initial Implementation For Jumbo Frames Test Suite
On Fri, 21 Jun 2024 17:19:21 -0400 Nicholas Pratte 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.
