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 12843A04E0 for ; Wed, 27 Nov 2019 15:30:23 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CE5962B96; Wed, 27 Nov 2019 15:30:22 +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 CBA43235 for ; Wed, 27 Nov 2019 15:30:21 +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-245-6zKhPPsOOzmAUurA46GZuA-1; Wed, 27 Nov 2019 09:30:14 -0500 Received: by mail-vk1-f197.google.com with SMTP id w131so574122vkd.0 for ; Wed, 27 Nov 2019 06:30:14 -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=k9kp4yuzjgJu/o9NnWCMBLqDOfWqIf1pOzyRDBsvK1JPPiD5b/frZ0mbvRfScJnkEN ESVWVxL8AJE9OxDhY6yg+vqdEaNcEWIWttZ7/KdTrwEqhv4Q+omL4DN5Yrws6gufPjAz ecXP9T60uDqqmjkXi7pVvB0mRtYydeC3zPYcnE5cm6Kun+cLOwD076/K97hS9nmD1Gq+ RMyWAa9lqjWZxAzV8r4/TYY1jWDXbKahLwXyEBSTyoYaiSzBUromJNfOCRtBRT/NnGLU yVkEZUk2XHl0mjLg7NuiM+WoC6Dr+xKbyFYFdNegXD9xApZsSwKYCtFwFvcaeqXJg/Fb j+pg== X-Gm-Message-State: APjAAAVI1To3davB401SOKbZ2GJZghrOPkGjlmF/gS69pJY5XasOzDp3 RpPT3iMhHjK1ins+Byzdemm8p/1SpCeGYQnQFOz0iHhuatVml2M+K9pF+cYrqLTu2PjXQTsSoyC ZZfiK5n6092uWvhHXT/1y5BY= X-Received: by 2002:a1f:cf43:: with SMTP id f64mr3053150vkg.18.1574865013319; 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: 6zKhPPsOOzmAUurA46GZuA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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" 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