From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by dpdk.org (Postfix) with ESMTP id 123F2AABF for ; Thu, 22 Mar 2018 07:53:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2127; q=dns/txt; s=iport; t=1521701580; x=1522911180; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=F1r8MTEAJeBWt7VTYQ8nlRXe0fy996uMmQp/waS8W7U=; b=lYu50SK/AF+Ij931h861uZFKj5grujOmygV3MBc6pr7uSvbDjT4hY8UH EEnXg3qRuOBVz40scg4rslGPg7619HRnIwai7AAxXfL15H5RJCNveDBx5 BV5g23fiwkUVCdoHljPM93UWHEPDpbRNc3Gn0ZF3BWSenkpu1F7JcHbRL w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AQCPUrNa/5tdJa1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYM9gVEoCotRjQyBcoEQkleCBguFBQKDVyE0GAECAQEBAQE?= =?us-ascii?q?BAmsohSUBAQEDAScTMQ4FBwQCAQgOAwQBAQEeCQcyFAkIAQEEDgUIhH4IrTg?= =?us-ascii?q?1iEKBe4UvghGBU0CBDIMGhFeFcQOXfggCiD2GK40Kj2UCERMBgSQBHDiBUnA?= =?us-ascii?q?Vgn2CHhuOFm+POgGBFQEB?= X-IronPort-AV: E=Sophos;i="5.48,343,1517875200"; d="scan'208";a="372099599" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2018 06:52:54 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w2M6qspH020902 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Mar 2018 06:52:54 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 22 Mar 2018 02:52:53 -0400 Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1320.000; Thu, 22 Mar 2018 02:52:53 -0400 From: "Hanoch Haim (hhaim)" To: Yongseok Koh CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] mlx5 reta size is dynamic Thread-Index: AdPBRlLwtkvkc0EZRb2Y20W7rzsPggAOXX8AAApoimA= Date: Thu, 22 Mar 2018 06:52:53 +0000 Message-ID: References: <1b6a9384a5604f15948162766cde90a9@XCH-RTP-017.cisco.com> <20180321214749.GA53128@yongseok-MBP.local> In-Reply-To: <20180321214749.GA53128@yongseok-MBP.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [64.103.125.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] mlx5 reta size is dynamic X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 06:53:01 -0000 Hi Yongseok,=20 RSS has a DPDK API,application can ask for the reta table size and configur= e it. In your case you are assuming specific use case and change the size d= ynamically which solve 90% of the use-cases but break the 10% use-case.=20 Instead, you could provide the application a consistent API and with that 1= 00% of the applications can work with no issue. This is what happen with In= tel (ixgbe/i40e) Another minor issue the rss_key_size return as zero but internally it is 40= bytes Thanks, Hanoh -----Original Message----- From: Yongseok Koh [mailto:yskoh@mellanox.com]=20 Sent: Wednesday, March 21, 2018 11:48 PM To: Hanoch Haim (hhaim) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] mlx5 reta size is dynamic On Wed, Mar 21, 2018 at 06:56:33PM +0000, Hanoch Haim (hhaim) wrote: > Hi mlx5 driver expert, >=20 > DPDK: 17.11 > Any reason mlx5 driver change the rate table size dynamically based on=20 > the rx- queues# ? The device only supports 2^n-sized indirection table. For example, if the n= umber of Rx queues is 6, device can't have 1-1 mapping but the size of ind = tbl could be 8, 16, 32 and so on. If we configure it as 8 for example, 2 ou= t of 6 queues will have 1/4 of traffic while the rest 4 queues receives 1/8= . We thought it was too much disparity and preferred setting the max size i= n order to mitigate the imbalance. > There is a hidden assumption that the user wants to distribute the=20 > packets evenly which is not always correct. But it is mostly correct because RSS is used for uniform distribution. The = decision wasn't made based on our speculation but by many request from mult= iple customers. > /* 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)); Thanks, Yongseok