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 CC361454F8; Wed, 26 Jun 2024 01:49:57 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BBE85402B5; Wed, 26 Jun 2024 01:49:55 +0200 (CEST) Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by mails.dpdk.org (Postfix) with ESMTP id 38A33402A9 for ; Wed, 26 Jun 2024 01:49:54 +0200 (CEST) Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-1fa244db0b2so25607715ad.3 for ; Tue, 25 Jun 2024 16:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1719359393; x=1719964193; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=bTrXBv0OkregvtGo+wBTRAHKVk86IJ9jj5q9ReFLpYo=; b=gu1PL8NWfawpkDUbFW2edjKvbnPqE0klI6GiT2PRDgueEWOcqh5M5PqJ9FMQEZh4s5 cDjrxtpEtLo3LkWxGYtRIzIdwSknolzAFC5TebtXxOuMv926OgT+wl8dya5nARyCvhIF kcSlGwEdHiCuejZJcKaIq4SDb4R0HjugYtPZiY8XCWvuU61B0I9s1BcWP2CnCES0VwVi j2E5FLGjkRp9IKjuokyzc3b7y4nG4dBSEfYKsmYyog7t/wWo5pOWqyOigk1wm6VXXg+q ZDtSGxVp3QARGu3Db3EumLAxxu6INXsP3IWNcQG0JZt5kvS7sWsGpJQA1ND43gKsdZbZ bArQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719359393; x=1719964193; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bTrXBv0OkregvtGo+wBTRAHKVk86IJ9jj5q9ReFLpYo=; b=jVyMnr/xKDGfif1BB4dTuAyWmM1P8vNDhHUJIPtkhNUvww3Y0ac7Uu03KOed58B2tu bny0QRM9N+sfwEWf+TX9k5ZIDhPtlIqed9Beq+J19aqc2Pw3Uxvl0hJ8gdiuDbAtowJF 9OcRB6k71sfYw4IrD76WjtC28kvtI/xq3SwRUayYlpiwvsa2mo5SBDztpC+JuFs4j8JD v25fXOQJ321SUiQQLCdFjaIUSxuOH3rkJaQablYhd/7LABhTkw6FCwFtvc2ehwcguxgS XrOs4xaUeB3GpjKtlfNQNMeR5N/uZOniyUN+G+Y/Vw/8xXritt9kVOGMayvh5kYQgIbK 90Zg== X-Forwarded-Encrypted: i=1; AJvYcCXMdk0Vg7G50aVSioE9WxSGeiWkNd9p2skY3d1R4r1HPa0x5GesNlR4T1qyNzglVmpHZf+INI2jGJZpzy4= X-Gm-Message-State: AOJu0YxIHa5rWLux+rXo2+WNMLjPkjgsKDB0f2mbTJG9WoGvg1B4Ppc7 qyFIwtpTK+9NBMokhkxkuW/3A0DUqnpC10VGFelif1qsk72BRfWVnbYZlxFPatw= X-Google-Smtp-Source: AGHT+IGTCK1IAkz8+2h+oy8etW5rdvBshS1on+J4fDmUVmhMpBR+zV7fA0t/O4XJYhWaao3k86tQZA== X-Received: by 2002:a17:902:db03:b0:1f9:ff61:f1a7 with SMTP id d9443c01a7336-1fa15937c38mr114960995ad.45.1719359393078; Tue, 25 Jun 2024 16:49:53 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1f9eb2f0353sm87232445ad.23.2024.06.25.16.49.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Jun 2024 16:49:52 -0700 (PDT) Date: Tue, 25 Jun 2024 16:49:50 -0700 From: Stephen Hemminger To: Nicholas Pratte Cc: Honnappa Nagarahalli , 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 , thomas@monjalon.net Subject: Re: [RFC PATCH v2] Initial Implementation For Jumbo Frames Test Suite Message-ID: <20240625164950.20a08606@hermes.local> In-Reply-To: References: <20240524183604.6925-1-npratte@iol.unh.edu> <20240621211920.14286-2-npratte@iol.unh.edu> <20240621151802.33021b4a@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 On Tue, 25 Jun 2024 15:57:02 -0400 Nicholas Pratte wrote: > 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: > > > > > > =20 > > > 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: > > > =20 > > >> +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. =20 > > > > > > 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. =20 > > The test cases should not concern themselves with individual PMD behavi= ors. They should be based on the API definition. > > =20 There is confusion in DPDK about Maximum Transmission Unit (MTU) vs Maximum= Receive Unit (MRU). For almost all things, they are the same thing, but technically there is a = difference. https://swamy2064.wordpress.com/2018/12/01/mtu-and-mru/