From: Stephen Hemminger <stephen@networkplumber.org>
To: Nicholas Pratte <npratte@iol.unh.edu>
Cc: juraj.linkes@pantheon.tech, dmarx@iol.unh.edu,
jspewock@iol.unh.edu, bruce.richardson@intel.com,
yoan.picchi@foss.arm.com, paul.szczepanek@arm.com,
Honnappa.Nagarahalli@arm.com, luca.vizzarro@arm.com,
probb@iol.unh.edu, dev@dpdk.org
Subject: Re: [RFC PATCH v2] Initial Implementation For Jumbo Frames Test Suite
Date: Fri, 21 Jun 2024 15:18:02 -0700 [thread overview]
Message-ID: <20240621151802.33021b4a@hermes.local> (raw)
In-Reply-To: <20240621211920.14286-2-npratte@iol.unh.edu>
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.
next prev parent reply other threads:[~2024-06-21 22:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-24 18:36 [RFC PATCH 0/1] Initial Implementation For Jumbo Frames Nicholas Pratte
2024-05-24 18:36 ` [RFC PATCH] Initial Implementation For Jumbo Frames Test Suite Nicholas Pratte
2024-06-21 21:13 ` [RFC PATCH v2 0/1] Initial Implementation For Jumbo Frames Nicholas Pratte
2024-06-21 21:19 ` [RFC PATCH v2] Initial Implementation For Jumbo Frames Test Suite Nicholas Pratte
2024-06-21 22:18 ` Stephen Hemminger [this message]
2024-06-21 23:54 ` Honnappa Nagarahalli
2024-06-25 19:57 ` Nicholas Pratte
2024-06-25 21:57 ` Thomas Monjalon
2024-06-25 23:49 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240621151802.33021b4a@hermes.local \
--to=stephen@networkplumber.org \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=dmarx@iol.unh.edu \
--cc=jspewock@iol.unh.edu \
--cc=juraj.linkes@pantheon.tech \
--cc=luca.vizzarro@arm.com \
--cc=npratte@iol.unh.edu \
--cc=paul.szczepanek@arm.com \
--cc=probb@iol.unh.edu \
--cc=yoan.picchi@foss.arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).