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 80A1242D5E; Mon, 26 Jun 2023 18:29:50 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5C90340223; Mon, 26 Jun 2023 18:29:50 +0200 (CEST) Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by mails.dpdk.org (Postfix) with ESMTP id A68EC4013F for ; Mon, 26 Jun 2023 18:29:49 +0200 (CEST) Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-1b7ef3e74edso7389255ad.0 for ; Mon, 26 Jun 2023 09:29:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687796989; x=1690388989; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ymzC/O45yWhiALoYRpqgINAzx8ndzvMiG5V2Y3iUyCA=; b=Yu2AT62gAlhwitFku8V1LDtHddaOsdZz6360AaU7gT+3AAO4gpmBpRxUEB728Mn7KL zru79Pn3BHf8Hw88OQmXQ7rkstujx+w2DdRDpN9MtUrWZMpRwzJevXkIiQQ8Sa6y3zk1 wuMHqcH4YBHn2bwF1M7SsEXZVkqOKP6KT8Tb/HTIY56meWLDVnPS2I0szEEsotjr4OSB DnGlOujW+pX2WCFjZrzpYAiWkxLICBLNgjD+8hGOWcivMePKg7mV5rghikdwb8YgoiH4 QhYZjslJ3XGe0YfAnb8MrvcxLqnhT+ab4cl/QvBzwXkD4d2nrcT7+mnzOGLnAmDThvME alGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687796989; x=1690388989; 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=ymzC/O45yWhiALoYRpqgINAzx8ndzvMiG5V2Y3iUyCA=; b=kra+hV1u6QGvyUzNQCgQVYj/+87/M4qUyRug4qOg/Kq8nlX937Cgcjb+tXA9CDNaZ1 jNF13RIf18AGq2KQ+M3SJP+V0/eYpbbGduX3k3eKXXfe2lXuPHO0i/CTjKLXo68HU32s Xzr9/RAyoaBOX4CDpk8Rei6P18+TIl70PhIRRV45qrmU2dI1wN2ENDybOL5LPMpe9aZl yx4wIQe0/iPyShf3l5ME6RoP+UUs6Ha7cQ0c0KiPdA0ljIw6+BCLQ/fswflkLYu4UaSc PEaf7B8KfZ2CT4UsDyJmPcfwGAMQnj6cJZJICvgwIgAizslHmt6YowgR4+muNnrYDd6V xotA== X-Gm-Message-State: AC+VfDyD6ktVjU+dfw2DFs+m54W3+xvdeG0HS5SotjH08Dqxbsbue0GC FhhsBBvLF6azwTBeZq/msKoWfz69HdzQ24tDvgw= X-Google-Smtp-Source: ACHHUZ4x9NhcyLTyRmw+ENqZj8ZxzX6btbw/Di8f5yGH7CbS5A1D6lGxQwlEboGmFpN69njUp98XiTJr1GGRUBzbOIM= X-Received: by 2002:a17:902:dace:b0:1b3:c7c1:8ded with SMTP id q14-20020a170902dace00b001b3c7c18dedmr4385585plx.27.1687796988464; Mon, 26 Jun 2023 09:29:48 -0700 (PDT) MIME-Version: 1.0 References: <20230625114829.7f49a9ff@hermes.local> In-Reply-To: From: Nageswara Rao Date: Mon, 26 Jun 2023 21:59:36 +0530 Message-ID: Subject: Re: DPDK22 issue: Unable to set more than 4 queues in Azure To: stephen@networkplumber.org, kparameshwar@vmware.com Cc: dev@dpdk.org, ASHIQUE CK Content-Type: multipart/alternative; boundary="000000000000f3528705ff0adb02" 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 --000000000000f3528705ff0adb02 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Issue is because of tap_mp_req_on_rxtx() sending msg.num_fds more than RTE_MP_MAX_FD_NUM fds for queues > 4. Looks like these tap driver changes are added as part of the below patch http://patches.dpdk.org/project/dpdk/patch/20220121042944.23929-1-kumarapar= amesh92@gmail.com/ On Mon, Jun 26, 2023 at 3:53=E2=80=AFPM Nageswara Rao = wrote: > Yes, we are using vdev_netvsc. Native netvsc PMD we are observing issues > in enabling multiple queues. > Though we have 6 DPDK cores, unable to configure more than 4 queues. > > On Mon, Jun 26, 2023 at 12:18=E2=80=AFAM Stephen Hemminger < > stephen@networkplumber.org> wrote: > >> On Thu, 22 Jun 2023 22:06:10 +0530 >> Nageswara Rao wrote: >> >> > Hi All, >> > >> > We are observing the following issue with DPDK22.11. We didn=E2=80=99t= find any >> > upstream patches for this issue on the DPDK github. Is there any known >> > issue, please let us know. >> > >> > >> > >> > *Issue:* >> > >> > On Azure platform, we are unable to configure more than 4 queues. When >> we >> > try to configure more than 4 queues its failing with =E2=80=9CEAL: Can= not send >> more >> > than 8 FDs=E2=80=9D error. >> > >> > Here I am pasting the working and failing testpmd logs. >> > >> > Please note that this issue is not observed in DPDK 21.11. >> > >> >> You should be using the native netvsc PMD, not the >> vdev_netvsc,failsafe,tap kludge. >> >> I don't work on Azure any more but I suspect the issue is that the defau= lt >> in the kernel for TAP is for the number of queues =3D=3D number of cores= . >> >> You aren't going to see any real benefit from having more queues than >> the number of DPDK cores. >> >> --000000000000f3528705ff0adb02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Issue is because of tap_mp_req_on_rx= tx() sending msg.num_fds more than=C2=A0RTE_MP_MAX_FD_NUM fds for queues &g= t; 4.
Looks like these tap driver changes are added as part of th= e below patch

On Mon, Jun 26, 2023 at 3:53=E2=80=AFPM Nageswar= a Rao <nagpen75@gmail.com> = wrote:
Yes, we are using vdev_netvsc. Native netvsc PMD we are observing = issues in enabling multiple queues.=C2=A0
Though we have 6 DPDK cores, = unable to configure more than 4 queues.

On Mon, Jun 26, 2023 at 12:18= =E2=80=AFAM Stephen Hemminger <stephen@networkplumber.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 22 Jun 2023 22:06:= 10 +0530
Nageswara Rao <n= agpen75@gmail.com> wrote:

> Hi All,
>
> We are observing the following issue with DPDK22.11. We didn=E2=80=99t= find any
> upstream patches for this issue on the DPDK github. Is there any known=
> issue, please let us know.
>
>
>
> *Issue:*
>
> On Azure platform, we are unable to configure more than 4 queues. When= we
> try to configure more than 4 queues its failing with =E2=80=9CEAL: Can= not send more
> than 8 FDs=E2=80=9D error.
>
> Here I am pasting the working and failing testpmd logs.
>
> Please note that this issue is not observed in DPDK 21.11.
>

You should be using the native netvsc PMD, not the vdev_netvsc,failsafe,tap= kludge.

I don't work on Azure any more but I suspect the issue is that the defa= ult
in the kernel for TAP is for the number of queues =3D=3D number of cores.
You aren't going to see any real benefit from having more queues than the number of DPDK cores.

--000000000000f3528705ff0adb02--