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 27D13439B8; Wed, 24 Jan 2024 18:16:50 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B5DCE402A6; Wed, 24 Jan 2024 18:16:49 +0100 (CET) Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by mails.dpdk.org (Postfix) with ESMTP id 768C140294 for ; Wed, 24 Jan 2024 18:16:48 +0100 (CET) Received: by mail-pj1-f51.google.com with SMTP id 98e67ed59e1d1-2906bd9f2ebso3017605a91.0 for ; Wed, 24 Jan 2024 09:16:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1706116607; x=1706721407; darn=dpdk.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=4hqUlUeIb6eghOu/yAkaKxybBQFm4t3Y1QZqWQpZFvI=; b=EYgwLcIL2uR/8J/vbp0PDx06K7xVCQ6SzPhAtyWUQ22HIPjO1XyAwBF/zF3DCa5XyR u0vUTSH/fSyNPrKfz09K07iGGFUkE1Z8EvUwaluO3B/D5YZs6VRrhtR2bGqJCO0fggks DmAV4L31ifBFls9Eq40y5l1MjR4ABzVrmau8k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706116607; x=1706721407; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=4hqUlUeIb6eghOu/yAkaKxybBQFm4t3Y1QZqWQpZFvI=; b=txl2oojbnJwu8XL+ROUY9PltD1YEOschDkHSzFujKEVE7eUOwTqNA0UPQHDKyPR4vy A0Mk5wm+KE7HKxQ8x7BerAO5aY1/Ky7i+/hJOpZY5SgHI13FxEIhBVDejHgHoGASlgfd xTxCc0d02AfI76Lo6/Iwt/XpghSTBGVJE/KWrZW+xlZB/9X8FyQheU8z/b37VM4zlsr6 MaOoB6cSSvChv91Udzdikh9p4jey6GhvocoisG24O3yxfGMER/q8HNr/TT/kL5W6pJvL 1pS/aLvn4uEOX1GoIeqmc11CrZW9yYRPkOcBuFC7IcFxMHmYBWs0/cccozuy7eRS8xdf iBjg== X-Gm-Message-State: AOJu0YzCbKZUSmoiFic20IHPhKFVXPYwJ8maf0Kpjc+F1K3R3crKFroe SyxUAcAsL18cpu9CDDWTKjCBhuR/pYIetA1Ho6vCqnngBhzmdWvBqpjkvg353uXKUBv33gg5NF7 L4t0Q4q9gcdCkiy2GPo/div5JLRegHm3sCKt7FltrzbtXO1GoKL0= X-Google-Smtp-Source: AGHT+IFXS6aIbg8rllM4f6jfjXak/RKG6W5mwJVSttj4pstiZbPWk3NX3+tLB05Vu6Lmz2zDLHhdM3cAP4ZlXv9i8rw= X-Received: by 2002:a17:90a:5382:b0:28d:afe2:1013 with SMTP id y2-20020a17090a538200b0028dafe21013mr2035412pjh.34.1706116607316; Wed, 24 Jan 2024 09:16:47 -0800 (PST) MIME-Version: 1.0 From: Jeremy Spewock Date: Wed, 24 Jan 2024 12:16:36 -0500 Message-ID: Subject: Testing scatter support for PMDs using testpmd To: dev@dpdk.org Cc: qi.z.zhang@intel.co, rasland@nvidia.com Content-Type: multipart/alternative; boundary="000000000000532fc8060fb43afb" 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 --000000000000532fc8060fb43afb Content-Type: text/plain; charset="UTF-8" Hello maintainers, In porting over the first ethdev suite to the new DTS framework, there was an inconsistency that we found and we were wondering if anyone would be able to shed some light on this. In general the inconsistency pertains to Intel and Mellanox NICs, where one will throw an error and not start testpmd while the other will work as expected. In the original DTS suite for testing scattered packets, testpmd is started with the flags --max-packet-len=9000 and --mbuf-size=2048. This starts and works fine on Intel NICs, but when you use the same flags on a Mellanox NIC, it will produce the error seen below. There is a flag that exists for testpmd called --enable-scatter and when this flag is provided, the Mellanox NIC seems to accept the flags and start without error. Our assumption is that this should be consistent between NICs, is there a reason that one NIC would allow for starting testpmd without explicitly enabling scatter and the other wouldn't? Should this flag always be present, and is it an error that testpmd can start without it in the first place? Here is the error provided when attempting to run on a Mellanox NIC: mlx5_net: port 0 Rx queue 0: Scatter offload is not configured and no enough mbuf space(2048) to contain the maximum RX packet length(9000) with head-room(128) mlx5_net: port 0 unable to allocate rx queue index 0 Fail to configure port 0 rx queues Start ports failed Thank you for any insight, Jeremy --000000000000532fc8060fb43afb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello maintainers,

In porting over the first ethdev suite to the= new DTS framework, there was an inconsistency that we found and we were wo= ndering if anyone would be able to shed some light on this. In general the = inconsistency pertains to Intel and Mellanox NICs, where one will throw an = error and not start testpmd while the other will work as expected.

In = the original DTS suite for testing scattered packets, testpmd is started wi= th the flags --max-packet-len=3D9000 and --mbuf-size=3D2048. This starts an= d works fine on Intel NICs, but when you use the same flags on a Mellanox N= IC, it will produce the error seen below. There is a flag that exists for t= estpmd called --enable-scatter and when this flag is provided, the Mellanox= NIC seems to accept the flags and start without error.

Our assumptio= n is that this should be consistent between NICs, is there a reason that on= e NIC would allow for starting testpmd without explicitly enabling scatter = and the other wouldn't? Should this flag always be present, and is it a= n error that testpmd can start without it in the first place?

Here is the = error provided when attempting to run on a Mellanox NIC:

mlx5_net: port 0 = Rx queue 0: Scatter offload is not configured and no enough mbuf space(2048= ) to contain the maximum RX packet length(9000) with head-room(128)
mlx5= _net: port 0 unable to allocate rx queue index 0
Fail to configure port = 0 rx queues
Start ports failed

Thank you for any insight,
Jeremy
--000000000000532fc8060fb43afb--