From: Patrick Robb <probb@iol.unh.edu>
To: Nicholas Pratte <npratte@iol.unh.edu>
Cc: yoan.picchi@foss.arm.com, ian.stokes@intel.com,
stephen@networkplumber.org, Honnappa.Nagarahalli@arm.com,
luca.vizzarro@arm.com, thomas@monjalon.net,
thomas.wilks@arm.com, dmarx@iol.unh.edu,
paul.szczepanek@arm.com, dev@dpdk.org,
Alex Chapman <alex.chapman@arm.com>
Subject: Re: [PATCH v1 2/2] dts: add mtu update and jumbo frames test suite
Date: Sun, 19 Jan 2025 20:47:32 -0500 [thread overview]
Message-ID: <CAJvnSUDSyzQLNWJ4G==o5g4xm_fnynu-oa7y=DJYFoDj2N+-_g@mail.gmail.com> (raw)
In-Reply-To: <20250117145838.40206-3-npratte@iol.unh.edu>
[-- Attachment #1: Type: text/plain, Size: 2995 bytes --]
On Fri, Jan 17, 2025 at 9:58 AM Nicholas Pratte <npratte@iol.unh.edu> wrote:
>
> + def assess_mtu_boundary(self, testpmd_shell: TestPmdShell, mtu: int)
> -> None:
> + """Sets the new MTU and verifies packets at the set boundary.
> +
> + Ensure that packets smaller than or equal to a set MTU will be
> received and packets larger
> + will not.
> +
> + First, start testpmd and update the MTU. Then ensure the new
> value appears
> + on port info for all ports.
> + Next, start packet capturing and send 3 different lengths of
> packet and verify
> + they are handled correctly.
> + # 1. VENDOR_AGNOSTIC_PADDING units smaller than the MTU
> specified.
> + # 2. Equal to the MTU specified.
> + # 3. VENDOR_AGNOSTIC_PADDING units larger than the MTU
> specified (should be fragmented).
> + Finally, stop packet capturing.
> +
> + Args:
> + testpmd_shell: Active testpmd shell of a given test case.
> + mtu: New Maximum Transmission Unit to be tested.
> + """
> + # Send 3 packets of different sizes (accounting for vendor
> inconsistencies).
> + # 1. VENDOR_AGNOSTIC_PADDING units smaller than the MTU specified.
> + # 2. Equal to the MTU specified.
> + # 3. VENDOR_AGNOSTIC_PADDING units larger than the MTU specified.
> + smaller_frame_size: int = mtu - VENDOR_AGNOSTIC_PADDING
> + equal_frame_size: int = mtu
> + larger_frame_size: int = mtu + VENDOR_AGNOSTIC_PADDING
> +
> + self.send_packet_and_verify(pkt_size=smaller_frame_size,
> should_receive=True)
> + self.send_packet_and_verify(pkt_size=equal_frame_size,
> should_receive=True)
> +
> + current_mtu = testpmd_shell.show_port_info(0).mtu
> + self.verify(current_mtu is not None, "Error grabbing testpmd MTU
> value.")
> + if current_mtu and (
> + current_mtu >= STANDARD_MTU + VENDOR_AGNOSTIC_PADDING and mtu
> == STANDARD_MTU
> + ):
> + self.send_packet_and_verify(pkt_size=larger_frame_size,
> should_receive=True)
>
I don't understand when this condition may be true - can you explain?
Thanks!
> + else:
> + self.send_packet_and_verify(pkt_size=larger_frame_size,
> should_receive=False)
> +
> + @func_test
> + def test_runtime_mtu_updating_and_forwarding(self) -> None:
> + """Verify runtime MTU adjustments and assess packet forwarding
> behavior.
> +
> + Test:
> + Start TestPMD in a paired topology.
> + Set port MTU to 1500.
> + Send packets of 1493, 1500 and 1509 bytes.
>
I think 1493 should be 1491.
> --
> 2.47.1
>
>
Thanks, other than a couple questions here and in the associated patch this
looks good. I can merge on Tuesday.
Reviewed-by: Patrick Robb <probb@iol.unh.edu>
Tested-by: Patrick Robb <probb@iol.unh.edu>
[-- Attachment #2: Type: text/html, Size: 4093 bytes --]
prev parent reply other threads:[~2025-01-20 1:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-17 14:58 [PATCH v1 0/2] dts: " Nicholas Pratte
2025-01-17 14:58 ` [PATCH v1 1/2] dts: add fwd restart decorator to rx capabilities Nicholas Pratte
2025-01-20 1:11 ` Patrick Robb
2025-01-17 14:58 ` [PATCH v1 2/2] dts: add mtu update and jumbo frames test suite Nicholas Pratte
2025-01-20 1:47 ` Patrick Robb [this message]
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='CAJvnSUDSyzQLNWJ4G==o5g4xm_fnynu-oa7y=DJYFoDj2N+-_g@mail.gmail.com' \
--to=probb@iol.unh.edu \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=alex.chapman@arm.com \
--cc=dev@dpdk.org \
--cc=dmarx@iol.unh.edu \
--cc=ian.stokes@intel.com \
--cc=luca.vizzarro@arm.com \
--cc=npratte@iol.unh.edu \
--cc=paul.szczepanek@arm.com \
--cc=stephen@networkplumber.org \
--cc=thomas.wilks@arm.com \
--cc=thomas@monjalon.net \
--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).