Re: [RFC PATCH v2] Initial Implementation For Jumbo Frames Test Suite

[Nicholas Pratte <npratte@iol.unh.edu>]

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