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