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 C4C17A0547; Mon, 5 Dec 2022 16:57:07 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 667E940156; Mon, 5 Dec 2022 16:57:07 +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 5097A4014F for ; Mon, 5 Dec 2022 16:57:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670255824; 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; bh=XZaoJxGegLIB0sFMIsZEK+0B9BUb4jF0I0qgMfL13mc=; b=NK3+9tuhhQQz0boI3nOxUAcPKJ1iqn5L8EakKNySafZnHbX9Bv3Ow+RhJpXosvg8kxJ3I7 Y2j7FFuUpZa0MlDuV3hUraNcm/n1nD3IjgcO6qEDcRG1mfNPI85SI1PPoVl1xj8Z5ZP1pW cIguL7du1i5QL5kwxxnQIeEa+gI6OnU= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-507-EULlYy0pOKWyfZDqgrL-Dg-1; Mon, 05 Dec 2022 10:57:03 -0500 X-MC-Unique: EULlYy0pOKWyfZDqgrL-Dg-1 Received: by mail-wm1-f70.google.com with SMTP id m34-20020a05600c3b2200b003cf549cb32bso8648698wms.1 for ; Mon, 05 Dec 2022 07:57:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=message-id:mime-version:to:from:subject:cc:date :content-transfer-encoding:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=XZaoJxGegLIB0sFMIsZEK+0B9BUb4jF0I0qgMfL13mc=; b=KkbFOH4U/kH1ngfLOC0kakX8hNzW4FKz+iDup+ByRWpOCjQCOXPJJUxf3iWSgl15nB dimCH9CruK7nzqhpfqn3up0/oVVFJrPFoQ2642wuMEn88Ya0p6aRBK7NSSOM0viWIDn/ +GLaQv28lcqz98hgFHWwvouYTtPhRm/D8n6r+4fNaGq+rpzu97hAH3X9VSMB3bx9IqN2 /mwcOvXMXWnEckftxSLoL8UVWt/PZ4YFmaEKwuqgz8Ys/KsvZ8jtQ2sna048LwKQqhX3 VJmHxLTC8gdnk0b/SkL2bBqf4ZFtEz8xvyAMaDuCzsynNhHmCJMeg6yzRMSQbzbcxrbC 6d+w== X-Gm-Message-State: ANoB5pnJ8ykV/UqNGr60TydvNS0MzHGMMoMaGSjQ6+7kY9VaKBjw23H6 xjH5fxeXIc5YJzHpHq4FosrZ90KctyN6jvWtTgwSdVLGn299QkNMTh0pcp4LM/qMM8A0DkpRim3 H/hk= X-Received: by 2002:a5d:5045:0:b0:242:199a:e067 with SMTP id h5-20020a5d5045000000b00242199ae067mr21128458wrt.148.1670255822197; Mon, 05 Dec 2022 07:57:02 -0800 (PST) X-Google-Smtp-Source: AA0mqf5DiDmMQK0Q0GqtkSn6kpXMpziscdq075gTilYVpGlJaRsfMK7hEMOQFxlYKEc0bvM3+ngQdQ== X-Received: by 2002:a5d:5045:0:b0:242:199a:e067 with SMTP id h5-20020a5d5045000000b00242199ae067mr21128443wrt.148.1670255821978; Mon, 05 Dec 2022 07:57:01 -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 e18-20020a5d4e92000000b0024206ed539fsm14381907wru.66.2022.12.05.07.57.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Dec 2022 07:57:01 -0800 (PST) Date: Mon, 05 Dec 2022 16:57:00 +0100 Cc: , "Kevin Traynor" , "Christophe Fontaine" , "" Subject: mlx5 rte_eth_dev_info.reta_size value From: "Robin Jarry" To: "Ori Kam" MIME-Version: 1.0 Message-ID: X-Mimecast-Spam-Score: 0 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 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.1= 41933-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(*conf)= ; 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_size; (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 the + * 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! --=20 Robin Jarry Principal Software Engineer Red Hat