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 C914E41CC1; Fri, 17 Feb 2023 18:38:42 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A64B840F18; Fri, 17 Feb 2023 18:38:42 +0100 (CET) Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by mails.dpdk.org (Postfix) with ESMTP id 813DF40EE3 for ; Fri, 17 Feb 2023 18:38:41 +0100 (CET) Received: by mail-pl1-f173.google.com with SMTP id k10so2002200plg.0 for ; Fri, 17 Feb 2023 09:38:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Zj/9rDOHP2ciLbp5lPXq1Pxb93JlQK6JgbjE4qIdpBo=; b=VWOwSoiIQIvFVfoQdXmHHMJuaYmLLf7txDcSv+y/vUijXrjP85axAf4YZNaU5XIeKQ c/gRlcDuO1eh1KtNWgLTAXnklJz5decTxd92PVwcZoKDAvKSS+bbVYx2hoLMzPAvjaFx bCtkIRv6kljW7qYDDnHs1cw7MrlJA0syJMDMzAfKr6CpvHVFEquQ1uaM4D3y0HrZrstU D0abYpXvbGl/LFFCAIEd+58T7kCyTw/Etns96vtQEGm2ghrHbVtdwMa/Dtkmkm9/d2A4 qPLd9gMqEeN0S70ch52MTJWkbVDMqjz4txLa6eeKVhvyfq5/PhF2F+IYxLgwUGupjeUK ZPbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=Zj/9rDOHP2ciLbp5lPXq1Pxb93JlQK6JgbjE4qIdpBo=; b=lCVkimH+9n/vzPfHZA8BBJoA8uwg2LdRrM+cn/GoBBBhPuLy7NeNe3UAoljBK2MI5Q Y5wH/0WmAG95JIGJyelUzslIWpOsGI9Jg/r9pPb7CuwKsWmPL/dlxdeMPN78k2U2Nd0A 342hEmRHUcS2EzpEda90rEdjiRhYVvCcOM4pXwkWn+im4tycsaE3/XzZQ1RfWsiK5QTE PN2Tr86KV/bbrbsD513QV1XHlbOBIxKg8vMAbA3f+J61y0O49grX1XDg0BLUSOqUEDW5 G764CZXopr8yAJsMUQNS3tt3d+DQDlYzYxVA2zuubtFkJhNRsGlLr8rFMwsmkbfEI4vl SNbA== X-Gm-Message-State: AO0yUKXDUOfMQmaThuD5S6+2lckcsaZsTOW745ULMyjLRVo7eTBR3L1F 2y6GT6pLYDMw0etRAxv6lYgNWdUa2LDs+Z/oxE4= X-Google-Smtp-Source: AK7set95s51fHCVWcUC5ivYQw1T6EqHkc+IIgsLTtwK7EbwckpsxGJVsPAjYmB2q8Cy16dhU4fRdDPtVtoDFgtCvUAE= X-Received: by 2002:a17:90b:390e:b0:233:c82d:c879 with SMTP id ob14-20020a17090b390e00b00233c82dc879mr1395521pjb.132.1676655520657; Fri, 17 Feb 2023 09:38:40 -0800 (PST) MIME-Version: 1.0 References: <20230216115109.07067372@hermes.local> In-Reply-To: From: Rajasekhar Pulluru Date: Fri, 17 Feb 2023 23:08:27 +0530 Message-ID: Subject: Re: Multiple Tx-Queues not working as expected To: Bruce Richardson Cc: stephen@networkplumber.org, dev@dpdk.org Content-Type: multipart/alternative; boundary="000000000000b83a9a05f4e8c812" 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 --000000000000b83a9a05f4e8c812 Content-Type: text/plain; charset="UTF-8" Yes Bruce, rte_eth_tx_burst api returns the same count as nb_pkts (4th-arg) Thanks for pointing out the information on tracking per-queue stats mapping, can try this out. Thanks & Regards, Rajasekhar On Fri, Feb 17, 2023 at 10:09 PM Bruce Richardson < bruce.richardson@intel.com> wrote: > On Fri, Feb 17, 2023 at 11:30:14AM +0530, Rajasekhar Pulluru wrote: > > Ok Stephen, thanks for the information, I can try that. > > One of the problems I see with single Tx Queue mode is that Ixia > > reports packet drops, though I confirmed with the help of counters > > (before invoking tx burst) that all packets are being sent-out. > Dumping > > HW counters don't report any drops in TX. > > Is there a mechanism in DPDK to debug this? > > Thanks & Regards, > > Rajasekhar > > > Hi, > > so long as the packets are written successfully to the TX ring, they should > be send out ok - unless the actual packets are some way invalid, e.g. > undersized. Are the tx_burst calls reporting that all packets are getting > written to the ring? All packets successfully written should be reported > as received at the other end. > > In terms of the NIC TX stats, I'm not sure about for the ixgbe driver, but > I think in some cases to get per-queue stats, you needed to set up a > mapping of what queues you wanted to track stats for, as the NIC could only > track a certain number of queues - fewer than that available in HW. See > function [1]. For tracking transmits per queue, it's generally easier just > to have the app track the successful enqueues to the ring. This is what > testpmd does internally for queue stats, I believe (though for port stats > it reads hardware). > > /Bruce > > [1] > https://doc.dpdk.org/api/rte__ethdev_8h.html#a56fae7e398b289f795a1b6256149c4f3 > --000000000000b83a9a05f4e8c812 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes Bruce, rte_eth_tx_burst api returns the same count as = nb_pkts (4th-arg)

Thanks for pointing out the informatio= n on tracking per-queue stats mapping, can try this out.=C2=A0
Thanks & Regards,
Rajasekhar

On Fri, Feb 17= , 2023 at 10:09 PM Bruce Richardson <bruce.richardson@intel.com> wrote:
On Fri, Feb 17, 2023 at 11:30:14AM +05= 30, Rajasekhar Pulluru wrote:
>=C2=A0 =C2=A0 Ok Stephen, thanks for the information, I can try that. >=C2=A0 =C2=A0 One of the problems I see with single Tx Queue mode is th= at Ixia
>=C2=A0 =C2=A0 reports packet drops, though I confirmed with the help of= counters
>=C2=A0 =C2=A0 (before invoking tx burst) that all packets are being sen= t-out. Dumping
>=C2=A0 =C2=A0 HW counters don't report any drops in TX.
>=C2=A0 =C2=A0 Is there a mechanism in DPDK to debug this?
>=C2=A0 =C2=A0 Thanks & Regards,
>=C2=A0 =C2=A0 Rajasekhar
>
Hi,

so long as the packets are written successfully to the TX ring, they should=
be send out ok - unless the actual packets are some way invalid, e.g.
undersized. Are the tx_burst calls reporting that all packets are getting written to the ring?=C2=A0 All packets successfully written should be repor= ted
as received at the other end.

In terms of the NIC TX stats, I'm not sure about for the ixgbe driver, = but
I think in some cases to get per-queue stats, you needed to set up a
mapping of what queues you wanted to track stats for, as the NIC could only=
track a certain number of queues - fewer than that available in HW.=C2=A0 S= ee
function [1]. For tracking transmits per queue, it's generally easier j= ust
to have the app track the successful enqueues to the ring. This is what
testpmd does internally for queue stats, I believe (though for port stats it reads hardware).

/Bruce

[1] https://doc.dpdk.o= rg/api/rte__ethdev_8h.html#a56fae7e398b289f795a1b6256149c4f3
--000000000000b83a9a05f4e8c812--