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 2AFA3A0093 for ; Mon, 7 Nov 2022 10:12:08 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B6C7942D28; Mon, 7 Nov 2022 10:12:05 +0100 (CET) Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) by mails.dpdk.org (Postfix) with ESMTP id EFE1342D10 for ; Fri, 4 Nov 2022 18:15:47 +0100 (CET) Received: by mail-ed1-f49.google.com with SMTP id i21so8549292edj.10 for ; Fri, 04 Nov 2022 10:15:47 -0700 (PDT) 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=FulzUjUVDAX2US/muQ3bZ7/6lKY+tT6z+a7+9a24uQs=; b=bJjNW+Zd98NESjK/Yi3zj5VAZ1GZseEVInIkNrpEFdit/vXVoJfXwPcx3vkUJFHvS+ 07lPARhB6jx4lP4Ja/ckjZ94Q5FmvstBk6wwghtyi6m1gtsTdB82hf3iB0fdP1tueyb+ SQscqPp5dMsbl3dxkAuNyMYEIsX/LlC9KLuZuOtNEEblku7tmA5NgWN/tlsioT8Xf8gl ghGOW1cO7jxll6uJfxN/WThcbkix9hyUeIskDEgg/8ada550SVPvRkciSOSq2mMdzhkV y9iWo9h05SlLJ4HHcz2P0C3jKhrwDyTHJO/2wM6sHI3xK/Iio3pcgjX0HstGK0d7Tdt+ KfwQ== 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=FulzUjUVDAX2US/muQ3bZ7/6lKY+tT6z+a7+9a24uQs=; b=tsJBfYpagmrX8qj3bnUdHb7MmoW71RCeuRz03veOwZtuRngbSP7UK3lmHXe7/Pwy3g kphGbyZcvLQk6FtWbslwnpDsLnCi8D4+zscAIad2ah7y08rR2AMziO/mthK70hv6+Cl+ Nuk72H4eOmjKekvkRUXXbJfP8xtbhu4xekPO0u2JHHPx216DLxtY/KGt5aXhTf4uJSar l2ukHvp5o6zzyaAqT5S217OuQMoVCIOmI11WhMx6wxFiP8covdMfsgq46vAijvX8NEfk 3EjB83HXraLmZLS2RFxNGMOfuQuFYW7VfQSKTjgrZDZRjeiZOS7dSou+R1Q7cOcllh6A wlDQ== X-Gm-Message-State: ACrzQf2hYxU78yvB8k4RS97ZYzDxP2aLUosoZf4TKEqAo4gRFIlNZCV0 aZ5vcvw2a/vr0oz1TQ9AslYM4qox+DUqhEYE3t68tq2rrqI= X-Google-Smtp-Source: AMsMyM68ekd0ApgI4Qq1DhIyPNlZlcPqMNHw1ww6BBSe1bOjtzYnoZYHQ36VYxKDRK4nKtHOfkDDdbGdR6VQ65CMfR8= X-Received: by 2002:a05:6402:550c:b0:443:7d15:d57f with SMTP id fi12-20020a056402550c00b004437d15d57fmr36991917edb.147.1667582147406; Fri, 04 Nov 2022 10:15:47 -0700 (PDT) MIME-Version: 1.0 References: <20221104095202.32c55020@hermes.local> In-Reply-To: <20221104095202.32c55020@hermes.local> From: Yang Luan Date: Fri, 4 Nov 2022 10:15:36 -0700 Message-ID: Subject: Re: Wrong rx queue assignment running DPDK on Azure To: Stephen Hemminger Cc: users@dpdk.org Content-Type: multipart/alternative; boundary="00000000000087afb005eca8398a" X-Mailman-Approved-At: Mon, 07 Nov 2022 10:12:05 +0100 X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --00000000000087afb005eca8398a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We use netvsc PMD (drivers/net/netvsc/). We don't explicitly configure the RETA table. We configure the device with 40 rx queues (rte_eth_dev_configure) and use rte_eth_dev_rss_reta_query() to query the RETA table (result posted earlier). On Fri, Nov 4, 2022 at 9:52 AM Stephen Hemminger wrote: > On Tue, 1 Nov 2022 17:25:24 -0700 > Yang Luan wrote: > > > Hello, > > > > > > Our application uses the net_netvsc driver in DPDK 21.08 on Azure. We > found > > an issue where RSS doesn=E2=80=99t deliver packets to the correct rx qu= eue. The > > instance type we use is Standard_L80s_v3 with MT27800 Family [ConnectX-= 5 > > Virtual Function] NICs. The NIC is configured with 40 rx queues and the > > RETA table is configured (confirmed by rte_eth_dev_rss_reta_query()) as > > below. > > > > > > > > 0: 0 1 2 3 4 5 6 7 > > > > 8: 8 9 10 11 12 13 14 15 > > > > 16: 16 17 18 19 20 21 22 23 > > > > 24: 24 25 26 27 28 29 30 31 > > > > 32: 32 33 34 35 36 37 38 39 > > > > 40: 0 1 2 3 4 5 6 7 > > > > 48: 8 9 10 11 12 13 14 15 > > > > 56: 16 17 18 19 20 21 22 23 > > > > 64: 24 25 26 27 28 29 30 31 > > > > 72: 32 33 34 35 36 37 38 39 > > > > 80: 0 1 2 3 4 5 6 7 > > > > 88: 8 9 10 11 12 13 14 15 > > > > 96: 16 17 18 19 20 21 22 23 > > > > 104: 24 25 26 27 28 29 30 31 > > > > 112: 32 33 34 35 36 37 38 39 > > > > 120: 0 1 2 3 4 5 6 7 > > > > > > > > One example is a packet received with rss key 0xEDE25D84 was incorrectl= y > > delivered to rx queue 12. We expect it to be queue 4 as 0xEDE25D84 & > 0x7F =3D > > 4 assuming seven of the least significant bits (LSBs) are used for > indexing > > into the RETA table. Is it a bug or we made a wrong assumption on how > the > > RETA table is accessed with that device? > > > > > > Thank you. > > > > Yang > > Are you using failsafe PMD or the native netvsc PMD? > Are you programming reta table via DPDK or through other API's? > --00000000000087afb005eca8398a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We use netvsc PMD (drivers/net/netvsc/).
We don't = explicitly configure the RETA table. We configure the device with 40 rx que= ues (rte_eth_dev_configure) and use rte_eth_dev_rss_reta_query() to query t= he RETA table (result posted earlier).

On Fri, Nov 4, 2022 at 9:52 AM = Stephen Hemminger <stephen= @networkplumber.org> wrote:
On Tue, 1 Nov 2022 17:25:24 -0700
Yang Luan <lua= n.penny@gmail.com> wrote:

> Hello,
>
>
> Our application uses the net_netvsc driver in DPDK 21.08 on Azure. We = found
> an issue where RSS doesn=E2=80=99t deliver packets to the correct rx q= ueue. The
> instance type we use is Standard_L80s_v3 with MT27800 Family [ConnectX= -5
> Virtual Function] NICs. The NIC is configured with 40 rx queues and th= e
> RETA table is configured (confirmed by rte_eth_dev_rss_reta_query()) a= s
> below.
>
>
>
>=C2=A0 =C2=A00:=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 1=C2=A0 =C2=A0= 2=C2=A0 =C2=A0 3=C2=A0 =C2=A0 4=C2=A0 =C2=A0 5=C2=A0 =C2=A0 6=C2=A0 =C2=A0= 7
>
>=C2=A0 =C2=A08:=C2=A0 =C2=A0 =C2=A0 =C2=A08=C2=A0 =C2=A0 9=C2=A0 =C2=A0= 10=C2=A0 =C2=A011=C2=A0 =C2=A012=C2=A0 =C2=A013=C2=A0 =C2=A014=C2=A0 =C2=A0= 15
>
>=C2=A0 16:=C2=A0 =C2=A0 =C2=A0 16=C2=A0 =C2=A017=C2=A0 =C2=A018=C2=A0 = =C2=A019=C2=A0 =C2=A020=C2=A0 =C2=A021=C2=A0 =C2=A022=C2=A0 =C2=A023
>
> 24:=C2=A0 =C2=A0 =C2=A0 24=C2=A0 =C2=A025=C2=A0 =C2=A026=C2=A0 =C2=A02= 7=C2=A0 =C2=A028=C2=A0 =C2=A029=C2=A0 =C2=A030=C2=A0 =C2=A031
>
> 32:=C2=A0 =C2=A0 =C2=A0 32=C2=A0 =C2=A033=C2=A0 =C2=A034=C2=A0 =C2=A03= 5=C2=A0 =C2=A036=C2=A0 =C2=A037=C2=A0 =C2=A038=C2=A0 =C2=A039
>
> 40:=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 1=C2=A0 =C2=A0 2=C2=A0 = =C2=A0 3=C2=A0 =C2=A0 4=C2=A0 =C2=A0 5=C2=A0 =C2=A0 6=C2=A0 =C2=A0 7
>
> 48:=C2=A0 =C2=A0 =C2=A0 =C2=A08=C2=A0 =C2=A0 9=C2=A0 =C2=A010=C2=A0 = =C2=A011=C2=A0 =C2=A012=C2=A0 =C2=A013=C2=A0 =C2=A014=C2=A0 =C2=A015
>
> 56:=C2=A0 =C2=A0 =C2=A0 16=C2=A0 =C2=A017=C2=A0 =C2=A018=C2=A0 =C2=A01= 9=C2=A0 =C2=A020=C2=A0 =C2=A021=C2=A0 =C2=A022=C2=A0 =C2=A023
>
> 64:=C2=A0 =C2=A0 =C2=A0 24=C2=A0 =C2=A025=C2=A0 =C2=A026=C2=A0 =C2=A02= 7=C2=A0 =C2=A028=C2=A0 =C2=A029=C2=A0 =C2=A030=C2=A0 =C2=A031
>
> 72:=C2=A0 =C2=A0 =C2=A0 32=C2=A0 =C2=A033=C2=A0 =C2=A034=C2=A0 =C2=A03= 5=C2=A0 =C2=A036=C2=A0 =C2=A037=C2=A0 =C2=A038=C2=A0 =C2=A039
>
> 80:=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 1=C2=A0 =C2=A0 2=C2=A0 = =C2=A0 3=C2=A0 =C2=A0 4=C2=A0 =C2=A0 5=C2=A0 =C2=A0 6=C2=A0 =C2=A0 7
>
> 88:=C2=A0 =C2=A0 =C2=A0 =C2=A08=C2=A0 =C2=A0 9=C2=A0 =C2=A010=C2=A0 = =C2=A011=C2=A0 =C2=A012=C2=A0 =C2=A013=C2=A0 =C2=A014=C2=A0 =C2=A015
>
> 96:=C2=A0 =C2=A0 =C2=A0 16=C2=A0 =C2=A017=C2=A0 =C2=A018=C2=A0 =C2=A01= 9=C2=A0 =C2=A020=C2=A0 =C2=A021=C2=A0 =C2=A022=C2=A0 =C2=A023
>
> 104:=C2=A0 =C2=A0 =C2=A0 24=C2=A0 =C2=A025=C2=A0 =C2=A026=C2=A0 =C2=A0= 27=C2=A0 =C2=A028=C2=A0 =C2=A029=C2=A0 =C2=A030=C2=A0 =C2=A031
>
> 112:=C2=A0 =C2=A0 =C2=A0 32=C2=A0 =C2=A033=C2=A0 =C2=A034=C2=A0 =C2=A0= 35=C2=A0 =C2=A036=C2=A0 =C2=A037=C2=A0 =C2=A038=C2=A0 =C2=A039
>
> 120:=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 1=C2=A0 =C2=A0 2=C2=A0 = =C2=A0 3=C2=A0 =C2=A0 4=C2=A0 =C2=A0 5=C2=A0 =C2=A0 6=C2=A0 =C2=A0 7
>
>
>
> One example is a packet received with rss key 0xEDE25D84 was incorrect= ly
> delivered to rx queue 12. We expect it to be queue 4 as 0xEDE25D84 &am= p; 0x7F =3D
> 4 assuming seven of the least significant bits (LSBs) are used for ind= exing
> into the RETA table.=C2=A0 Is it a bug or we made a wrong assumption o= n how the
> RETA table is accessed with that device?
>
>
> Thank you.
>
> Yang

Are you using failsafe PMD or the native netvsc PMD?
Are you programming reta table via DPDK or through other API's?
--00000000000087afb005eca8398a--