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 C64A3A04E0; Wed, 27 Nov 2019 15:30:24 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 32B712C60; Wed, 27 Nov 2019 15:30:24 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id 89705235 for ; Wed, 27 Nov 2019 15:30:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574865021; 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=BYuq9/mKxJilExxnkxv7iFPaFWNcM8zsXPF4Z8ITMCY=; b=byJ6D9i6fB5xZvjvsAT5E6uPUnHGEwQgiO0QzXPlnTqCEj9mXdBC7MW0s/IQ47YqgT2mM4 5l1rJRd0ewpP+zyoecLpP3/kQ+t8udSdEbeEH5PjG0IbCbZRAbvIMkrRjSZ8qArac4uYS4 QY29vBize0A1mNxKY0uZBcIgrU0ncic= Received: from mail-vk1-f197.google.com (mail-vk1-f197.google.com [209.85.221.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-195-Y-zlDPJbPPK3BNbr00P9jA-1; Wed, 27 Nov 2019 09:30:13 -0500 Received: by mail-vk1-f197.google.com with SMTP id v71so10573624vkd.16 for ; Wed, 27 Nov 2019 06:30:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/uCg2fJBYP1ixycRG6R8EshmCnt5sYChFPV8aMBgq24=; b=pCUM7i4K5qJNp5CB4YqQomfV8vWoa7aZ83++qcRk4PKjoIBTcIr/Pko82atxleFtgK mh2aDgSX3ELM49ocu6hfLi0DNP0guuRjMaeunn1AajAIMtt5OiGf5vMoy7uTMTxXX8yl TiRgnu/oP6BPfgWtZr683/+vA83QMF/WNQ55nRxRgTFdyhVylcXOTflAusTGRWdwc3fC 04fSGSe0cM0wCTw5I9PFgaPg0+/xMscPqHDw/YnjtEPFXsiEqog7PQfJSglainJSYWxZ xj8xuJeMF+82ayDQRjECefAzcNjPa1HOKtwvslZWgFoamN2TwBA2HkuLXtFU6AlT9AWb gc4w== X-Gm-Message-State: APjAAAWhZ0VWqGP3+bxRaqr7M+c6wEEfgxaGR2QK5Bs3izvdl77OwnPh 0y46kQ+j/wh6QmFe85/gZEJQVWRZ9y2ZDK8XdrDwm0hqNzUqIHD45WdUCEJo0kUX9vBzXmwc044 EJcY75Udv09b1ak9Xa1c= X-Received: by 2002:a1f:cf43:: with SMTP id f64mr3053144vkg.18.1574865013317; Wed, 27 Nov 2019 06:30:13 -0800 (PST) X-Google-Smtp-Source: APXvYqw5hPSfTmUyP+UQUjFgaYTuZKzpJjnJ/q54FGMX0GI+Mugr/cuTHLliC4JXgT2pycWIN65697aoyJ0UuD/wY9k= X-Received: by 2002:a1f:cf43:: with SMTP id f64mr3053115vkg.18.1574865012874; Wed, 27 Nov 2019 06:30:12 -0800 (PST) MIME-Version: 1.0 References: <20191127134213.9003-1-thomas@monjalon.net> <237226cc-c734-2386-273b-f86fe4c829ef@intel.com> <7429394.Qh3vguxsr8@xps> In-Reply-To: <7429394.Qh3vguxsr8@xps> From: David Marchand Date: Wed, 27 Nov 2019 15:30:01 +0100 Message-ID: To: Thomas Monjalon Cc: Ferruh Yigit , Matan Azrad , Shahaf Shuler , Viacheslav Ovsiienko , Jasvinder Singh , Cristian Dumitrescu , Andrew Rybchenko , dev , dpdk stable , Raslan Darawsheh X-MC-Unique: Y-zlDPJbPPK3BNbr00P9jA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH] ethdev: limit maximum number of queues 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Nov 27, 2019 at 3:11 PM Thomas Monjalon wrote= : > > 27/11/2019 15:07, David Marchand: > > On Wed, Nov 27, 2019 at 3:06 PM Ferruh Yigit w= rote: > > > > > > 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. This gigantic value also documents that the driver has no limitation itself= . The limitation is in the ethdev layer. Certainly a bit far-fetched but, with the mlx5 driver as a .so, you would prefer the driver not to announce a limitation from ethdev if you recompile ethdev. -- David Marchand