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 33C1F454F8; Wed, 26 Jun 2024 00:06:10 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0045B402B5; Wed, 26 Jun 2024 00:06:09 +0200 (CEST) Received: from fhigh3-smtp.messagingengine.com (fhigh3-smtp.messagingengine.com [103.168.172.154]) by mails.dpdk.org (Postfix) with ESMTP id 990FC402A9 for ; Wed, 26 Jun 2024 00:06:08 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailfhigh.nyi.internal (Postfix) with ESMTP id DFB6411401BD; Tue, 25 Jun 2024 17:57:46 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 25 Jun 2024 17:57:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1719352666; x=1719439066; bh=nqvQsVOPmazfXz/awrzMVYLgRC7ZkrEXF+bjQUIGBo8=; b= EPo467Tm8bAc2QGIhfjrUkafzUmtUuf64cnPIu1qbU9sPPPoWsHm1DYGbt9TxRKX LQG8r7PqQgqIPgLFvZdN5avWZBDTv/H8s9HKnLfShfioZ5htPGN+i8s4GUrHufwX aI8uw48Y4ulOhop/cYEg4tvEL9j1YZvxF2fOZodlTPcAMuwMy+VHnbVWD6sLCmeA ul058s3aLMbibMMHmONeHqzRUrtWlzgW8xgDqtg1B+jQnZnguFCUP77ZYiWDnsFS bHReiJIQGIzrXbQlligjP2f0oj1jq9TM6WwHFTxA9CKf6ajdMY1tXlGRN15QXp7I XkQut8xMU1oLitNfkv+Y9A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1719352666; x= 1719439066; bh=nqvQsVOPmazfXz/awrzMVYLgRC7ZkrEXF+bjQUIGBo8=; b=k WdYM4fqiymH4R4jr2bzMKegXd7iMIbiqkwXkdKZoUj8G/6l8qYFe3vjrhjoQUSsj i0ZJGE6E0jy4EiPMN+qiq8JtcwWbXymQhnNSinw0P1xFKRRZSszu0t4Md2+4HgUI pq+tagWQXiFy6c5I4OYyoBqnGl7JPIEEgq4gClMWtUkWqIi7dDs3hLLYoeV1RSdw 0+ZsEEOeXduoyt2XvIq7EKp7S/b9Kc0odrCuAvVo5Z+TRFJElSvO7DNAjK0xF2IS 6wpUh+ooDH3QlQdqvoOGBcVIC03G05nIS6G0hk8QaYJb9pVH/WFAqTKZwbUDjwIj kFWUXP/4zyP+xYLFx9dcw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrtddugddtgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepgedttdeljeejgeffkeekkedtjeevtdehvedtkeeivdeuuedviedu vdelveejueejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 25 Jun 2024 17:57:44 -0400 (EDT) From: Thomas Monjalon To: Nicholas Pratte , ferruh.yigit@amd.com Cc: Honnappa Nagarahalli , Stephen Hemminger , Juraj =?utf-8?B?TGlua2XFoQ==?= , "dmarx@iol.unh.edu" , "jspewock@iol.unh.edu" , "Richardson, Bruce" , "yoan.picchi@foss.arm.com" , Paul Szczepanek , Luca Vizzarro , Patrick Robb , "dev@dpdk.org" , nd , david.marchand@redhat.com Subject: Re: [RFC PATCH v2] Initial Implementation For Jumbo Frames Test Suite Date: Tue, 25 Jun 2024 23:57:41 +0200 Message-ID: <2534694.xXo6FtjLZv@thomas> In-Reply-To: References: <20240524183604.6925-1-npratte@iol.unh.edu> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 Nicholas, you are writing a test for the API. You should not adapt to the driver behaviour. If the driver does not report what we can expect from the API definition, it is a bug. =46erruh, please can you explain what is the problem with MTU sizes? 25/06/2024 21:57, Nicholas Pratte: > 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. >=20 > 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. >=20 > On Fri, Jun 21, 2024 at 7:55=E2=80=AFPM Honnappa Nagarahalli > wrote: > > > > > > > > > On Jun 21, 2024, at 5:18=E2=80=AFPM, Stephen Hemminger wrote: > > > > > > On Fri, 21 Jun 2024 17:19:21 -0400 > > > Nicholas Pratte wrote: > > > > > >> +The test suite ensures the consistency of jumbo frames transmission= within > > >> +Poll Mode Drivers using a series of individual test cases. If a Pol= l Mode > > >> +Driver receives a packet that is greater than its assigned MTU leng= th, 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 MT= U 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 fo= llowing test suite > > >> +evaluates the behavior within all possible edge cases, ensuring tha= t 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 receiv= e an up to 2K packet. > > > This never caused any problem for upper layer protocols, just some pi= cky conformance tests. > > The test cases should not concern themselves with individual PMD behavi= ors. They should be based on the API definition. > > >=20