From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id B5AB1A04E0 for ; Wed, 27 Nov 2019 15:11:19 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 782BC1BE0C; Wed, 27 Nov 2019 15:11:19 +0100 (CET) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by dpdk.org (Postfix) with ESMTP id 18B7B28EE; Wed, 27 Nov 2019 15:11:17 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 8EE8761D6; Wed, 27 Nov 2019 09:11:15 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 27 Nov 2019 09:11:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=WUN4yk+uwNsb/FUgMm9lSlZopjYZvevr+fVXkGJWnnE=; b=DorAow/Udwv9 mr1lVlLIgFxDsfY6UuXJRofcVjfqAGO9DJVM1WOvT5Yj/RVyHR87yXwlvVaqBeZE A4fHyqLu1GIo8L+AMoYHdQUkFpLMlq/lvy0CPFrugFPNqmu3E5JeIlKcA0oCtso3 LxV0RT9xkUl8GwMcwVMUdK+7EPosLMM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=WUN4yk+uwNsb/FUgMm9lSlZopjYZvevr+fVXkGJWn nE=; b=EbDvj1eBEzNqwixsMmqnztoAq+rwaxa6RRplJOSWk2TyQTJF2IzWhNDTF Lu6scIYHgndkhUJCDs0XPmkT+pd09GD5dCtI7H4tpuNiTvjUfUPmsZbil9a3Nvbx r5CbDMBpgoQcK3h8Fbcy+d/rfFjRrpI6CWGCzgLa70kMJxBEzG2egc98xNUt4m08 7GqeUXz0zACP3CdH1WnBQmIdxuSs5rz9QiZvXCFF9UZiCLG6oPdk8fG8QbyNndkZ 3HW3aowBx8v/z5kVDkDXQfWZdWDviPFiZjlD6+0U0N1BsUC60y9wuVV8Cyw18b0D IMkVShydr4f84JlHn3tEkdzGxfHHA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeihedgheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 81D32306005C; Wed, 27 Nov 2019 09:11:13 -0500 (EST) From: Thomas Monjalon To: David Marchand , Ferruh Yigit Cc: Matan Azrad , Shahaf Shuler , Viacheslav Ovsiienko , Jasvinder Singh , Cristian Dumitrescu , Andrew Rybchenko , dev , dpdk stable , Raslan Darawsheh Date: Wed, 27 Nov 2019 15:11:11 +0100 Message-ID: <7429394.Qh3vguxsr8@xps> In-Reply-To: References: <20191127134213.9003-1-thomas@monjalon.net> <237226cc-c734-2386-273b-f86fe4c829ef@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-stable] [PATCH] ethdev: limit maximum number of queues X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" 27/11/2019 15:07, David Marchand: > On Wed, Nov 27, 2019 at 3:06 PM Ferruh Yigit wrote: > > > > On 11/27/2019 1:42 PM, Thomas Monjalon wrote: > > > A buffer overflow happens in testpmd with some drivers > > > since the queue arrays are limited to RTE_MAX_QUEUES_PER_PORT. > > > > > > The advertised capabilities of mlx4, mlx5 and softnic > > > for the number of queues were the maximum number: UINT16_MAX. > > > They must be limited by the configured RTE_MAX_QUEUES_PER_PORT > > > that applications expect to be respected. > > > > > > The limitation is applied in above drivers having no limitation, > > > and at ethdev level (function rte_eth_dev_info_get), in order > > > to force the configured limit for all drivers. > > > > The limit is not device limit, should we reflect it into PMDs? > > Why not keep the limit only in the ethdev? > > +1. Yes ethdev is enough. I thought it would be better to document the limit in the PMDs as well, instead of keeping gigantic max. I can change if you feel strong about it.