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

[Stephen Hemminger <stephen@networkplumber.org>]

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/