DPDK patches and discussions
 help / color / mirror / Atom feed
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 --]

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