From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id ED79646074; Mon, 20 Jan 2025 02:50:27 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9252F402A4; Mon, 20 Jan 2025 02:50:27 +0100 (CET) Received: from mail-ua1-f48.google.com (mail-ua1-f48.google.com [209.85.222.48]) by mails.dpdk.org (Postfix) with ESMTP id CEC544029B for ; Mon, 20 Jan 2025 02:50:25 +0100 (CET) Received: by mail-ua1-f48.google.com with SMTP id a1e0cc1a2514c-85bafa89d73so720009241.2 for ; Sun, 19 Jan 2025 17:50:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1737337825; x=1737942625; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+GmWMSdzyimb2z3et9CLJR/EZCfM9kRbbpA5mXb6jGA=; b=SImeHYyHKWx7O2n+hQy7Zuv42u2LtuFEwMiK4GG0ZBijr5AVWOmknodwcXXjFXkeTU 54du7ntMvLv85ZFCR9O6CGsoGS4Mi6FiVdHGXMv/qxjo98JGso40kozIeyXF9FesxRh5 TN4Q3oDqeYBHB3rdLc1mb2agSk4K77ER6q1bs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737337825; x=1737942625; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+GmWMSdzyimb2z3et9CLJR/EZCfM9kRbbpA5mXb6jGA=; b=GSgGB1/SayhWqu2xlCESK7zOH2o6g7YSa8tYVxeRQ17QNObPuSPtqTDPxVWWyC+vmA w6obU8xo6yFZDHbOUfKMVgq7he19GfOblatxyr1YTkgszursQwrU1zAgOLxC3StmZuJP qetDaANc1xfZ7QXiORH8gDFdYE7lITOmediyZFkpN/7kX3NM9vDHXha9UQyI/C1WuMue ufZc3hSkhce+rnTrXi14W1G5JofsfrqmkxxfMHRd9psNcI4105vnokLvSxPV8EORbtSp DVVKVPlYGDxg80W9NLM/ZtEVppxVnIs2s9EfM72rx8k5YfdxztSE6iC8ao4MTDEHCwim WMCQ== X-Forwarded-Encrypted: i=1; AJvYcCU06cxxe/0wXudtAvvo9sMLH+uwQgqhZoVSD6T1b4Nd8xAEHWZ/0zSFQThCOX/bj8SOyQw=@dpdk.org X-Gm-Message-State: AOJu0YwdNC1tKPpQTOzGumhiMfAyB885A+T5V2Ei698YL4PvMZqzmixj OWNaq/wq9iZPatmUlES8xraSAkWaGcdzrdF211WvEO3rr5Yw8AzvEVtQTjZlZoZEZw+xZ5hpwLY n6nJ/uIWckLkkMmGluKM1HK/C1+RSm8vnlxqE5w== X-Gm-Gg: ASbGncuqr+kXPaJMBTZUVibDdM8RyjxruapGGQ5VD6EJYD4CcigY3iRVoTP64TPMJu9 4vCa5jbjgN494zzQ/+rfFaiJhJfDN/iUYVey1+35agntS5+urNL15My8PDPjMX87antg= X-Google-Smtp-Source: AGHT+IHWCTlwvyk0ob5MhbULrnk3312BYb5neS95r37PxcPYV3Vo08ZT3F+Rdo3798E7Fr5DxAeWLqhwVDbRwaAn8CQ= X-Received: by 2002:a05:6102:358e:b0:4b2:5c0a:9afa with SMTP id ada2fe7eead31-4b690b7de41mr8265855137.4.1737337825170; Sun, 19 Jan 2025 17:50:25 -0800 (PST) MIME-Version: 1.0 References: <20250117145838.40206-1-npratte@iol.unh.edu> <20250117145838.40206-3-npratte@iol.unh.edu> In-Reply-To: <20250117145838.40206-3-npratte@iol.unh.edu> From: Patrick Robb Date: Sun, 19 Jan 2025 20:47:32 -0500 X-Gm-Features: AbW1kvYsP0xujIC7UiNCL-dUnEbkdgaP5URNA50kNY4DLOtiY8-YdPWI8e52COg Message-ID: Subject: Re: [PATCH v1 2/2] dts: add mtu update and jumbo frames test suite To: Nicholas Pratte 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 Content-Type: multipart/alternative; boundary="000000000000ecb376062c197b04" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --000000000000ecb376062c197b04 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 17, 2025 at 9:58=E2=80=AFAM Nicholas Pratte 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 specifie= d. > + # 2. Equal to the MTU specified. > + # 3. VENDOR_AGNOSTIC_PADDING units larger than the MTU specified= . > + smaller_frame_size: int =3D mtu - VENDOR_AGNOSTIC_PADDING > + equal_frame_size: int =3D mtu > + larger_frame_size: int =3D mtu + VENDOR_AGNOSTIC_PADDING > + > + self.send_packet_and_verify(pkt_size=3Dsmaller_frame_size, > should_receive=3DTrue) > + self.send_packet_and_verify(pkt_size=3Dequal_frame_size, > should_receive=3DTrue) > + > + current_mtu =3D 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 >=3D STANDARD_MTU + VENDOR_AGNOSTIC_PADDING and = mtu > =3D=3D STANDARD_MTU > + ): > + self.send_packet_and_verify(pkt_size=3Dlarger_frame_size, > should_receive=3DTrue) > I don't understand when this condition may be true - can you explain? Thanks! > + else: > + self.send_packet_and_verify(pkt_size=3Dlarger_frame_size, > should_receive=3DFalse) > + > + @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 Tested-by: Patrick Robb --000000000000ecb376062c197b04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jan 17,= 2025 at 9:58=E2=80=AFAM Nicholas Pratte <npratte@iol.unh.edu> wrote:

+=C2=A0 =C2=A0 def assess_mtu_boundary(self, testpmd_shell: TestPmdShell, m= tu: int) -> None:
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 """Sets the new MTU and verifie= s packets at the set boundary.
+
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 Ensure that packets smaller than or equal to a= set MTU will be received and packets larger
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 will not.
+
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 First, start testpmd and update the MTU. Then = ensure the new value appears
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 on port info for all ports.
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 Next, start packet capturing and send 3 differ= ent lengths of packet and verify
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 they are handled correctly.
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # 1. VENDOR_AGNOSTIC_PADDING uni= ts smaller than the MTU specified.
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # 2. Equal to the MTU specified.=
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # 3. VENDOR_AGNOSTIC_PADDING uni= ts larger than the MTU specified (should be fragmented).
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 Finally, stop packet capturing.
+
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 Args:
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 testpmd_shell: Active testpmd sh= ell of a given test case.
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mtu: New Maximum Transmission Un= it to be tested.
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 """
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 # Send 3 packets of different sizes (accountin= g for vendor inconsistencies).
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 # 1. VENDOR_AGNOSTIC_PADDING units smaller tha= n the MTU specified.
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 # 2. Equal to the MTU specified.
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 # 3. VENDOR_AGNOSTIC_PADDING units larger than= the MTU specified.
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 smaller_frame_size: int =3D mtu - VENDOR_AGNOS= TIC_PADDING
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 equal_frame_size: int =3D mtu
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 larger_frame_size: int =3D mtu + VENDOR_AGNOST= IC_PADDING
+
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 self.send_packet_and_verify(pkt_size=3Dsmaller= _frame_size, should_receive=3DTrue)
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 self.send_packet_and_verify(pkt_size=3Dequal_f= rame_size, should_receive=3DTrue)
+
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 current_mtu =3D testpmd_shell.show_port_info(0= ).mtu
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 self.verify(current_mtu is not None, "Err= or grabbing testpmd MTU value.")
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 if current_mtu and (
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 current_mtu >=3D STANDARD_MTU= + VENDOR_AGNOSTIC_PADDING and mtu =3D=3D STANDARD_MTU
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 ):
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.send_packet_and_verify(pkt_= size=3Dlarger_frame_size, should_receive=3DTrue)

<= /div>
I don't understand when this condition may=C2=A0be true - can= you explain? Thanks!
=C2=A0
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 else:
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.send_packet_and_verify(pkt_= size=3Dlarger_frame_size, should_receive=3DFalse)
+
+=C2=A0 =C2=A0 @func_test
+=C2=A0 =C2=A0 def test_runtime_mtu_updating_and_forwarding(self) -> Non= e:
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 """Verify runtime MTU adjustmen= ts and assess packet forwarding behavior.
+
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 Test:
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Start TestPMD in a paired topolo= gy.
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Set port MTU to 1500.
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Send packets of 1493, 1500 and 1= 509 bytes.

I think 1493 should be 1491.=
=C2=A0
--
2.47.1


Thanks, other than a couple questions = here and in the associated patch this looks good. I can merge on Tuesday.= =C2=A0

Reviewed-by: Patrick Robb <probb@iol.unh.edu>
Tested-by: Patr= ick Robb <probb@iol.unh.edu>=
--000000000000ecb376062c197b04--