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 71AED454AE; Thu, 20 Jun 2024 21:24:28 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6317842E67; Thu, 20 Jun 2024 21:24:28 +0200 (CEST) Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) by mails.dpdk.org (Postfix) with ESMTP id EFF4342E5A for ; Thu, 20 Jun 2024 21:24:27 +0200 (CEST) Received: by mail-pg1-f180.google.com with SMTP id 41be03b00d2f7-6e41550ae5bso966191a12.3 for ; Thu, 20 Jun 2024 12:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1718911467; x=1719516267; 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=Q34DtoxTldIVnzkmagvJg+jvPUiN5jCFqyX5RuW1Sc4=; b=bIAcGfEgq/nM1bEFpiF9gm3vheqZXDnORr1sjhoCA+xFXvMJRMUSpg4fkTkRmIvcpd j9s/RG0vt+1lLhro+YFNZr+QMMrOmiiePuSrQJn+zY9aQrnW3NeLQomXAiyZDOiDUXTY BMFvwi2zW74MM/yUdf22d52T0QaMHNgoF7PfE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718911467; x=1719516267; 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=Q34DtoxTldIVnzkmagvJg+jvPUiN5jCFqyX5RuW1Sc4=; b=LwIw91lkQgR903/VZwUQPYMyUYGHqvTMciStom1VGa1JsQNVrGp1TM86aGjgH5kM8/ gdEt9F8cvaSS621Ltkw4PT0hTvYOdRIWRVF7dnIBDRxLtMbCEMUYnSraZ0YWqnuwWhPr M+nQs87DxsD3DLU7YwSdXhpCQyJxab0cHtq/v3+EaItT821bORFC5VdD1zvmviRMX4aw wVo5ZynLRRts2YATTZuUoyOw9Mfc7icv3C0CgojeYDBcUqid+v9vKgjh74zVI6GO95wt q3FXB8sllIOuJE53gSMgG2vtiGkJkaa1DAYcARqlL8CMbji5/K4tv9eVploaisoII82f GUNw== X-Forwarded-Encrypted: i=1; AJvYcCUfNOCyJURi3eyQ6A0jcRA64urlxsdj8ohd8c4kO3QMGDeC+8Yr7/3TImh5CoGa40UjR5Ef5eYltqq1c54= X-Gm-Message-State: AOJu0YzZBr+OgeOrIxe4T7g/b9J1jrmdVkrbpv8P+juavS493lY6mcGy IlXe1S2p3yQF+fJ8IAWRQ2GvWX7HC0sH5mNRvsRMOdk6anqWxnVjorBwmOHR8stsbvGJr1O1aOL 3Dv30YqytV76FtV8IRvEfPGyTJ3uLlNPwrM1wHA== X-Google-Smtp-Source: AGHT+IGlYzVw63KBR/2MwIR6r9eURy3fDVCs9yYICWLLvEQF3gH7q1gDzfyMBr3ABIHTegzTEocIOiONaEemr3UC088= X-Received: by 2002:a17:90a:e60d:b0:2c4:a7af:4d79 with SMTP id 98e67ed59e1d1-2c7b5c75d03mr6205093a91.11.1718911466919; Thu, 20 Jun 2024 12:24:26 -0700 (PDT) MIME-Version: 1.0 References: <20240514201436.2496-1-jspewock@iol.unh.edu> <20240613181510.30135-1-jspewock@iol.unh.edu> <20240613181510.30135-5-jspewock@iol.unh.edu> <1f919017-0a1b-400b-9aae-441186db954c@pantheon.tech> In-Reply-To: <1f919017-0a1b-400b-9aae-441186db954c@pantheon.tech> From: Jeremy Spewock Date: Thu, 20 Jun 2024 15:24:15 -0400 Message-ID: Subject: Re: [PATCH v4 4/4] dts: add test case that utilizes offload to pmd_buffer_scatter To: =?UTF-8?Q?Juraj_Linke=C5=A1?= Cc: probb@iol.unh.edu, yoan.picchi@foss.arm.com, npratte@iol.unh.edu, Honnappa.Nagarahalli@arm.com, wathsala.vithanage@arm.com, paul.szczepanek@arm.com, Luca.Vizzarro@arm.com, thomas@monjalon.net, dev@dpdk.org 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 Wed, Jun 19, 2024 at 4:51=E2=80=AFAM Juraj Linke=C5=A1 wrote: > > > > - def scatter_pktgen_send_packet(self, pktsize: int) -> str: > > + def scatter_pktgen_send_packet(self, pktsize: int) -> list[Packet]= : > > A note: We should make this method a part of TestSuite (so that we have > a common way to filter packets across all test suites) in a separate > patchset as part of https://bugs.dpdk.org/show_bug.cgi?id=3D1438. That's a good idea. > > > """Generate and send a packet to the SUT then capture what is= forwarded back. > > > > Generate an IP packet of a specific length and send it to the= SUT, > > - then capture the resulting received packet and extract its pay= load. > > - The desired length of the packet is met by packing its payload > > + then capture the resulting received packets and filter them do= wn to the ones that have the > > + correct layers. The desired length of the packet is met by pac= king its payload > > with the letter "X" in hexadecimal. > > > > Args: > > pktsize: Size of the packet to generate and send. > > > > Returns: > > - The payload of the received packet as a string. > > + The filtered down list of received packets. > > """ > > > > > with testpmd_shell as testpmd: > > testpmd.set_forward_mode(TestPmdForwardingModes.mac) > > + # adjust the MTU of the SUT ports > > + for port_id in range(testpmd.number_of_ports): > > + testpmd.set_port_mtu(port_id, 9000) > > For a second I thought about maybe somehow using the decorator from the > previous patch, but that only works with testpmd methods. > > But then I thought about us setting this multiple times (twice (9000, > then back to 1500) in each test case) and that a "better" place to put > this would be set_up_suite() (and tear_down_suite()), but that has a > major downside of starting testpmd two more times. Having it all in one > place in set_up_suite() would surely make the whole test suite more > understandable, but starting testpmd multiple times is not ideal. Maybe > we have to do it like in this patch. Right, I ended up putting it here just because the shell was already started here so it was convenient, but setting the MTU and resetting it multiple times is also definitely not ideal. I'm not really sure of exactly the best way to handle it either unfortunately. Something else I could do is have my own boolean that just tracks if the MTU has been updated yet and only do it the first time, but then there would have to be some kind of way to track which case is the last one to run which is also a whole can of worms. I think overall the cost of switching MTUs more than we need to is less than that of starting testpmd 2 extra times with only these two test cases, but if more are added it could end up being the opposite. As a note though, from what I have recently seen while testing this, this change of MTU seems like it is generally needed when you are bound to the kernel driver while running DPDK instead of vfio-pci. One of the parameters that is passed into testpmd in this suite is --max-pkt-len and this adjusts the MTU of the ports before starting testpmd. However, since some NICs use the kernel driver as their driver for DPDK as well, this is not sufficient in all cases since the MTU of the kernel interface is not updated by this parameter and the packets still get dropped. So, for example, if you start testpmd with a Mellanox NIC bound to mlx5_core and the parameter --max-pkt-len=3D9000, the MTU of the port when you do a `show port info 0` will be 8982, but if you do an `ip a` command you will see that the network interface still shows an MTU value of 1500 and the packets will be dropped if they exceed the MTU set on the network interface. In all cases the MTU must be higher than 2048, so I set it using testpmd to be agnostic of which driver you are bound to, as long as it is a DPDK driver. I'm not sure if this is a bug or intentional because of something that blocks the updating of the network interface for some reason, but it might be worth mentioning to testpmd/ethdev maintainers regardless and I can raise it to them. If the `--max-pkt-len` parameter did update this MTU or always allowed receiving traffic at that size then we would not need to set the MTU in any test cases and it would be handled by testpmd on startup. In the meantime, there has to be this manual adjustment of MTU for the test cases to pass on any NIC that runs DPDK on its kernel driver. > > I also noticed that we don't really document why we're setting MTU to > 9000. The relation between MTU and mbuf size (I think that relation is > the reason, correct me if I'm wrong) should be better documented, > probably in set_up_suite(). It isn't as much to do with the relation to the mbuf size as much as it is to test the scattering of packets you have to send and receive packets that are greater than that mbuf size so we have to increase the MTU to transmit those packets. Testpmd can run with the given parameters (--mbuf-size=3D2048, --max-pkt-len=3D9000, or both together) without the MTU change, but as I alluded to above, the MTU in testpmd isn't always true to what the network interface says it is. > > > testpmd.start() > > > > for offset in [-1, 0, 1, 4, 5]: > > - recv_payload =3D self.scatter_pktgen_send_packet(mbsiz= e + offset) > > - self._logger.debug( > > - f"Payload of scattered packet after forwarding: \n= {recv_payload}" > > - ) > > + recv_packets =3D self.scatter_pktgen_send_packet(mbsiz= e + offset) > > + self._logger.debug(f"Relevant captured packets: \n{rec= v_packets}") > > + > > self.verify( > > - ("58 " * 8).strip() in recv_payload, > > + any( > > + " ".join(["58"] * 8) in hexstr(pakt.getlayer(2= ), onlyhex=3D1) > > + for pakt in recv_packets > > + ), > > "Payload of scattered packet did not match expect= ed payload with offset " > > f"{offset}.", > > ) > > + testpmd.stop() > > This sneaked right back in. It did, but this time it actually is needed. With the MTU of ports being reset back to 1500 at the end of the test, we have to stop packet forwarding first so that the individual ports can be stopped for modification of their MTUs.