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 2198C454B7; Fri, 21 Jun 2024 10:32:10 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E3A4C402F1; Fri, 21 Jun 2024 10:32:09 +0200 (CEST) Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) by mails.dpdk.org (Postfix) with ESMTP id B2F574026A for ; Fri, 21 Jun 2024 10:32:07 +0200 (CEST) Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-57d21b1c8efso1709302a12.3 for ; Fri, 21 Jun 2024 01:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.tech; s=google; t=1718958727; x=1719563527; darn=dpdk.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=nvZr/xrCc7JHSA/MdLYUwu/VjvYzERIIaKXAbWz5Dn0=; b=jj7X4or2IsnO+cwwsluKm+27UABJWR7lJSDTdnyYJABSkpSYqwgRKQpU95jf4Hxd+l ZMWVoWhHSi162F6zzDZES5q8qlz60hNBTGYB6WHIEyVS/5PuBBwNGekuAL95yQdXGscy PkY8/o5EJK/1+90MU7bkFYYaAag+PApLPfAxnx8TnmQ+mEpsNtyQ+HDFY4ejVcgfNbuV cN1R7noVHNEa3G7LTfE+lYdVebWXTtcIWtiVnPUpBsxh0N+CDFnPQA5C9DEHml8gAI2I IijqjnnOoOTvYqxk+gDk0nmPAU/Vb0DEEEl+SviUpUTMk2uQG7IfBsTzAa0bJoi2cYOg GTag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718958727; x=1719563527; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nvZr/xrCc7JHSA/MdLYUwu/VjvYzERIIaKXAbWz5Dn0=; b=whV6l4kwqPyRUzV8zYIz3X/qjLZYy/YSwgXK/iZ8XN6tC6+/hFV1ZncjB8CqaTN4wW 9ewjTVsACHWx4wWdU1JG9zklCCTr/LYtKuZWr0mz9f0YgTeA44O50uGHp+tHBqs1sHjz 0St9rScwOPf6IhNIypbnLkZ1DC+0sCw+xUyDnaVt7mT5iU0LHFPpXCTJqHdUBsbAyAUo TXMIWu9Eh/t/3dyZekTIVy8aX7JyzM/WNVc3ae54OCDoZ3nJ0oYlZrZuO9fduCiulBpU dRUczbDj9jSzOLUUuB8mh9eVgjWgtfw/07T25nif7PVKNnPnvq8na7WQohIXmX1pFoRc rXpQ== X-Forwarded-Encrypted: i=1; AJvYcCUcmIT4XQdP5f6EMOejl6qT+MFkXdJU0ozrYLS65fwsw0l7H6Ml848HJzf+NZnrAouCkLTyB4i6ccbe8uo= X-Gm-Message-State: AOJu0Ywf2OFv3S3Kbq4tgIznw3K/hyWtucW3wjXoaVsJhc5tWa/plyYC fOjvfcWNNZoAQI0f+JKe1zrtVnk9SSg+3Vd0nbdEvzbMMp2nvMwlt9EGWPFyvXc= X-Google-Smtp-Source: AGHT+IEQ09EE0WIseiZdL48teqCKKqXAytTi9hM2kZf5Gzjn25JOoYNuk27M8iVACwnOogYGTY2rkQ== X-Received: by 2002:a50:d79e:0:b0:57c:7f0d:304c with SMTP id 4fb4d7f45d1cf-57d07e2732cmr4150962a12.1.1718958726706; Fri, 21 Jun 2024 01:32:06 -0700 (PDT) Received: from [192.168.1.113] ([84.245.121.236]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-57d3056301bsm610633a12.89.2024.06.21.01.32.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Jun 2024 01:32:06 -0700 (PDT) Message-ID: <97b57966-4133-43ed-8afc-7fa4b36a59bb@pantheon.tech> Date: Fri, 21 Jun 2024 10:32:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 4/4] dts: add test case that utilizes offload to pmd_buffer_scatter To: Jeremy Spewock 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 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> Content-Language: en-US From: =?UTF-8?Q?Juraj_Linke=C5=A1?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 >>> 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=9000, 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. > This is interesting. So the "--max-pkt-len" parameter doesn't set the MTU in kernel if bound to a kernel driver, but the testpmd command ("port config mtu {port_id} {mtu}") does that properly? The most obvious thing to think would be that both should be configuring the command the same way. In that case, it sound like some sort of race condition when starting testpmd. Or something has to be done differently when setting MTU during init time, in which case it's not a bug but we should try to understand the reason. Or it could be something entirely different. We should talk to the maintainers or maybe look into testpmd code to figure out whether there's a difference in how the two ways differ. >> >> 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=2048, --max-pkt-len=9000, 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. > That's basically what I meant by relation between MTU and mbuf size :-). Let's put a clear reason for increasing the MTU into the set_up_suite docstring: that it must be higher than mbuf so that we're receiving packets big enough that don't fit into just one buffer. We currently just say we need to "support larger packet sizes", but I'd like to be more explicit with a reason for needing the larger packet size and how large the packets actually need to be, as it may not be obvious, since we're setting MTU way higher than 2048 (+5). >> >>> testpmd.start() >>> >>> for offset in [-1, 0, 1, 4, 5]: >>> - recv_payload = self.scatter_pktgen_send_packet(mbsize + offset) >>> - self._logger.debug( >>> - f"Payload of scattered packet after forwarding: \n{recv_payload}" >>> - ) >>> + recv_packets = self.scatter_pktgen_send_packet(mbsize + offset) >>> + self._logger.debug(f"Relevant captured packets: \n{recv_packets}") >>> + >>> self.verify( >>> - ("58 " * 8).strip() in recv_payload, >>> + any( >>> + " ".join(["58"] * 8) in hexstr(pakt.getlayer(2), onlyhex=1) >>> + for pakt in recv_packets >>> + ), >>> "Payload of scattered packet did not match expected 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. Oh, we can't modify the MTU while the port is running. I missed that, thanks.