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 D7966A0543; Tue, 6 Dec 2022 13:09:29 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7F3D740687; Tue, 6 Dec 2022 13:09:29 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 3572B4021D for ; Tue, 6 Dec 2022 13:09:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670328566; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9k0sG2UHUr5utNm/VOuOWn3waNY5xtk63s+9Ytr1pdo=; b=T5iVW3EieDV2ToPdQCyGniOPrCmieZXcs0Hyt8LGk8pbg7LdCIYGbc0uODHHMkhJzFRheX Un59KlaUoJRNGpsKKCT+H7xJlnL8Bv2TmPO2ope/VuT2cM84I5myibYcW6Z/3OFiLtIk0t 71pRvx7ZTViF9El73ccqDpvKvy+yH2w= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-575-NGOvyR21Md6dvZla6M452g-1; Tue, 06 Dec 2022 07:09:25 -0500 X-MC-Unique: NGOvyR21Md6dvZla6M452g-1 Received: by mail-wm1-f71.google.com with SMTP id bg25-20020a05600c3c9900b003cf3ed7e27bso8352019wmb.4 for ; Tue, 06 Dec 2022 04:09:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=9k0sG2UHUr5utNm/VOuOWn3waNY5xtk63s+9Ytr1pdo=; b=zpAVT1QKuNUaSiKJ2FnKV0LrTO/5bd6MJySjTVrs5B+Vt8ObCdGnttd5TRx6Q4i90P B+MUVZCj10ze0QR46cGnsB+Wgpz8ErnTXudjCMjrlV7bfCkQ73isnSyOAJu0QpveryVA J+P5/Wlo6rDTgvvqik8rNMSMJJwVmHZUoghmXQP+dcQgXHVWSmDjT84qIXeMGzDs1Sta 6sutCfB1grSPPMa1xY/irU2FenRBi4T9t/cEoZdsJqT3wxeeUwu2/WkL7Y1SBRTl4dVn AoDHhVSE+0+05N5eMHmuq03BIfdtERzZVyJ0VR0Ugs6K34U376HcDjDASTpZ7nVVKwGD XwwQ== X-Gm-Message-State: ANoB5pmSYrWWA1GzCHhPLfGbk36xo/w620hTwzUxSbf9Sy5X77xVJvqO ddlpQ6yXnAe5Xzd9bqR622q8R5Zn1ndre/ZJdzI3PftBSfyugc1l9SpBXWIBEQSThUrQvHFCrT8 12Ps= X-Received: by 2002:a5d:4104:0:b0:242:4f41:142e with SMTP id l4-20020a5d4104000000b002424f41142emr8714108wrp.332.1670328564310; Tue, 06 Dec 2022 04:09:24 -0800 (PST) X-Google-Smtp-Source: AA0mqf4aG4S00nsARl3TMRu+HhrnC4sP+Ki+AImkjJjgRrsHmhN2pNsT8U9cSW2oHJesgZjzjfH/+Q== X-Received: by 2002:a5d:4104:0:b0:242:4f41:142e with SMTP id l4-20020a5d4104000000b002424f41142emr8714088wrp.332.1670328564017; Tue, 06 Dec 2022 04:09:24 -0800 (PST) Received: from localhost (2a01cb000f483e0055ae3800781b5cbc.ipv6.abo.wanadoo.fr. [2a01:cb00:f48:3e00:55ae:3800:781b:5cbc]) by smtp.gmail.com with ESMTPSA id he10-20020a05600c540a00b003b4a699ce8esm23850735wmb.6.2022.12.06.04.09.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Dec 2022 04:09:23 -0800 (PST) Mime-Version: 1.0 Date: Tue, 06 Dec 2022 13:09:23 +0100 Message-Id: Cc: , "Kevin Traynor" , "Christophe Fontaine" , "" Subject: Re: mlx5 rte_eth_dev_info.reta_size value From: "Robin Jarry" To: "Ori Kam" , "Nelio Laranjeiro" X-Mailer: aerc/0.13.0-119-gb80c96126e5d References: In-Reply-To: X-Mimecast-Spam-Score: 1 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 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 Robin Jarry, Dec 05, 2022 at 16:57: > Hi Ori, > > While working on a patch for OvS[1], I have tried to reconfigure the > redirection table using the code examples that are layout around in > testpmd and other places. > > [1]: http://patchwork.ozlabs.org/project/openvswitch/patch/20221021145308= .141933-1-rjarry@redhat.com/ > > Here is a stripped down version of the code I use: > > int update_reta(int port_id, int num_rxq) > { > struct rte_eth_rss_reta_entry64 *conf; > struct rte_eth_dev_info info; > size_t conf_size; > int err; > > rte_eth_dev_info_get(port_id, &info); > conf_size =3D (info.reta_size / RTE_ETH_RETA_GROUP_SIZE) * sizeof(*con= f); > conf =3D malloc(conf_size); > memset(conf, 0, conf_size); > > for (uint16_t i =3D 0; i < info.reta_size; i++) { > uint16_t idx =3D i / RTE_ETH_RETA_GROUP_SIZE; > uint16_t shift =3D i % RTE_ETH_RETA_GROUP_SIZE; > reta_conf[idx].mask |=3D 1ULL << shift; > reta_conf[idx].reta[shift] =3D i % num_rxq; > } > err =3D rte_eth_dev_rss_reta_update(port_id, conf, info.reta_size); > free(conf); > > return err; > } > > This works well for i40e and ice drivers but I get very confusing > reta_size values with mlx5. > > mlx5_ethdev.c > > 333=E2=94=9C> info->reta_size =3D priv->reta_idx_n ? > 334=E2=94=82 priv->reta_idx_n : config->ind_table_max_siz= e; > > (gdb) p priv->reta_idx_n > $5 =3D 2 > (gdb) p config->ind_table_max_size > $6 =3D 512 > > Obviously, info.reta_size / RTE_ETH_RETA_GROUP_SIZE =3D 1 / 512 =3D 0 > > From what I had understood info.reta_size should be a multiple of > RTE_ETH_RETA_GROUP_SIZE. This is what I can observe with i40e and ice at > least. Is it possible that the mlx5 driver has an issue there? > > I found this commit[2] from 2015 that may have introduced an issue but > I am surprised that no one has ever encountered that before me. The > suspicious code bit is: > > + /* If the requested number of RX queues is not a power of two, use t= he > + * maximum indirection table size for better balancing. > + * The result is always rounded to the next power of two. */ > + reta_idx_n =3D (1 << log2above((rxqs_n & (rxqs_n - 1)) ? > + priv->ind_table_max_size : > + rxqs_n)); > > When rxqs_n =3D=3D 2, reta_idx_n is initialized to 2 as well. > > [2]: https://git.dpdk.org/dpdk/commit/?id=3D634efbc2c8c05 > > If you can provide any help, that would be much appreciated. > > Thanks! To make sure, I have written a simple program that reuses log2above: #include static unsigned int log2above(unsigned int v) { unsigned int l, r; for (l =3D 0, r =3D 0; (v >> 1); ++l, v >>=3D 1) r |=3D (v & 1); return l + r; } void main(void) { for (unsigned n =3D 1; n < 16; n++) { printf("n_rxq=3D%d -> reta_size=3D%d\n", n, 1 << log2above((n & (n - 1)) ? 512 : n)); } } Running this yields: n_rxq=3D1 -> reta_size=3D1 n_rxq=3D2 -> reta_size=3D2 n_rxq=3D3 -> reta_size=3D512 n_rxq=3D4 -> reta_size=3D4 n_rxq=3D5 -> reta_size=3D512 n_rxq=3D6 -> reta_size=3D512 n_rxq=3D7 -> reta_size=3D512 n_rxq=3D8 -> reta_size=3D8 n_rxq=3D9 -> reta_size=3D512 n_rxq=3D10 -> reta_size=3D512 n_rxq=3D11 -> reta_size=3D512 n_rxq=3D12 -> reta_size=3D512 n_rxq=3D13 -> reta_size=3D512 n_rxq=3D14 -> reta_size=3D512 n_rxq=3D15 -> reta_size=3D512 There is obviously something wrong and I am not sure what was the original intention. So I don't know what to do to fix this. I added Nelio in the thread. Maybe he can help :) Cheers.