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 B7FBF45538; Mon, 1 Jul 2024 18:45:57 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A69AC402B7; Mon, 1 Jul 2024 18:45:57 +0200 (CEST) Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by mails.dpdk.org (Postfix) with ESMTP id 7F60E4014F for ; Mon, 1 Jul 2024 18:45:56 +0200 (CEST) Received: by mail-lj1-f172.google.com with SMTP id 38308e7fff4ca-2ee59cffe01so1913311fa.0 for ; Mon, 01 Jul 2024 09:45:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1719852356; x=1720457156; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fzRRhtYFk8KtI51XB/x0jd3O9WHAVbtIs5XIHTGbauc=; b=JmTl/FSIKNjoVpxHeHWe1iCdEt6P//l1K4lHSQ+qJyLurm2twpVX+bltuJzPImwP2t NOs/JRm6O8ZDNPzsWt4/94T/tgf2pT2eshlaM1ZBcPizjX86QoeFPGzP6wVWJrV+Vnhz DBVVC61Qo7zQ06DiY5oMHrolAj1DQfXblLDHc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719852356; x=1720457156; h=content-transfer-encoding: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=fzRRhtYFk8KtI51XB/x0jd3O9WHAVbtIs5XIHTGbauc=; b=miQdu0GEa6JcKavYqzYhUfCnLIh8O5SayczY83Q2MusHnNo3Avd1zomDtHErZ6Nsd+ dJUQScOxCaAW1biC1fdO2hqL8qbviL/Se6bk9nhiz779eaaKCuDMzxqvjWSWB+M1SDZJ FXfuqMBWFu5Opsy2C5+lctIQKALjCVve6d6MbiSftlRcDKEXiYgtO4iIACpDhnyLOCWy MJqStJCRDdBNjsYtkHTZGvzNLd+FiPE801Yh8ywRw4taU4oVPppGs5ryGRNFybR1JoJI j1TjvJiBg+hi/IKW7uY73KXSP8Nb3W8tSwb9bpInyq8fVGxHfZB/NNAQRZodIsgeQyrq s8dg== X-Forwarded-Encrypted: i=1; AJvYcCWLwFtOHtA2J8evjfm8raXaiTo5xJaDKC53C/5OO1vjxGkOgpSNwgfcYHbJ5FxRlfDmPOIf/+C+mSxwDHk= X-Gm-Message-State: AOJu0YwUFsIfhFHjK0eN6FovBFD7bEOsdOP9hereYDfi5VyW4yO1pup6 TbRVwibDnIWCXQLVuPw1iQlZzgRiqQ0kjebpZIwGAs9wy9r1rigc8lYrIu/ax3lXjHZfPsxeAVu QQmdcIpz7gPGCIluQp01jI/IcSZnmBsIvwGiHwA== X-Google-Smtp-Source: AGHT+IGWmBB3A9MVjrkDAYFn/nxpGKrF/k9NjFV3GgOi3Hmuo6I1DSMk4Q3JLkknUcSCr2+S31pSePYmON2/LxSOwUE= X-Received: by 2002:a2e:a7d5:0:b0:2ec:ca8:4897 with SMTP id 38308e7fff4ca-2ee5e6ca046mr43852271fa.4.1719852355850; Mon, 01 Jul 2024 09:45:55 -0700 (PDT) MIME-Version: 1.0 References: <20240524183604.6925-1-npratte@iol.unh.edu> <2534694.xXo6FtjLZv@thomas> In-Reply-To: <2534694.xXo6FtjLZv@thomas> From: Nicholas Pratte Date: Mon, 1 Jul 2024 12:45:44 -0400 Message-ID: Subject: Re: [RFC PATCH v2] Initial Implementation For Jumbo Frames Test Suite To: Thomas Monjalon Cc: ferruh.yigit@amd.com, Honnappa Nagarahalli , Stephen Hemminger , =?UTF-8?Q?Juraj_Linke=C5=A1?= , "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 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 If I would like to create a test suite that is driver agnostic, then I would need to increase the boundaries at which I conduct each individual test case. Right now, I test jumbo frame behavior -1, +1, or at the MTU boundary. But, packets in TestPMD are dropped or forwarded based on the MTU size plus additional ethernet overhead. We would need to agree on a universal expected value for ethernet overhead across all devices, or come up with another solution. I created a Bugzilla ticket to discuss this further, it might make sense to discuss this outside of this thread. https://bugs.dpdk.org/show_bug.cgi?id=3D1476 On Tue, Jun 25, 2024 at 5:57=E2=80=AFPM Thomas Monjalon wrote: > > 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. > > Ferruh, 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. > > > > 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. > > > > 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 transmissi= on within > > > >> +Poll Mode Drivers using a series of individual test cases. If a P= oll Mode > > > >> +Driver receives a packet that is greater than its assigned MTU le= ngth, 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 = MTU 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 = following test suite > > > >> +evaluates the behavior within all possible edge cases, ensuring t= hat a test Poll > > > >> +Mode Driver strictly abides by the above implications. > > > > > > > > There are some weird drivers where MRU and MTU are not the same thi= ng. > > > > 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 rece= ive an up to 2K packet. > > > > This never caused any problem for upper layer protocols, just some = picky conformance tests. > > > The test cases should not concern themselves with individual PMD beha= viors. They should be based on the API definition. > > > > > > > > > >