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.nagaraha...@arm.com> wrote: > > > > > On Jun 21, 2024, at 5:18 PM, Stephen Hemminger <step...@networkplumber.org> > > wrote: > > > > On Fri, 21 Jun 2024 17:19:21 -0400 > > Nicholas Pratte <npra...@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. >
