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 86AFEA04E0 for ; Wed, 27 Nov 2019 15:07:58 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 67DE85596; Wed, 27 Nov 2019 15:07:58 +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 7576F2B8E for ; Wed, 27 Nov 2019 15:07:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574863674; 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=+MNhfoNgspg8IOcCwVrNY988nUG/eyHGI2XdG5kzAxE=; b=GFkJUwUmNfTs/qtekv69hrbbx7HUA9GSnFWmMIr2wSGYoLKCKfBiFYr+BsG2ikFoTRPY7O StMgUXJHiBfw/SEpR43pjnvGgUXxtwRJUEDLtpJ1O0e4zOLiNtRdP4pYyIc91kazofoKPx 84M0K61MJ+XB7PszEaWE8UczMavEvms= Received: from mail-vk1-f198.google.com (mail-vk1-f198.google.com [209.85.221.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-11-uJx9HoulMkSvkq_nc9Ycfg-1; Wed, 27 Nov 2019 09:07:53 -0500 Received: by mail-vk1-f198.google.com with SMTP id o144so10549266vko.13 for ; Wed, 27 Nov 2019 06:07:53 -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=GL2PQeR6REBp70YWAdItY5+RxvV/PnJd5WF4WA6vnJ4=; b=SvPhWfL5L+C+BWfdtsp4De+YN2jfjFt4KdLD07FmViNsjcz/9MfexpmHURiv8Xacns U1Ka2rbXkxfqGOiIIe9kVh69oegH7uo9bjcMDSkktr0u9+PDe8opK+SU2NCMbOjJ53xu ekFCx4TXD0ODURLfPPS8z0r919wEtPiLu/xmgzM23eXl2cfWLtcx/N74ZxoQcHNAplL6 NJA8IUra4yKtGY065QytSmTSnAa3xHUxuy1ecMP6x3eVym8vNjjkSqYk0FROiwE6N9qo u8JvcomobG6iq4qIXqrHAmk+QtgCLZdG4FSWiUYlXicIIVkzF58nBTL8si9VrWXA+Xqt R3lg== X-Gm-Message-State: APjAAAXFOu3WSK8+Ee8QD+eBFo4gc1JvnUTGRXzIMUsHg5zepv+7tdjJ IHFxGJspsbb6Bu9exHiL6L+KOMU7J579CG9RXGAKIub+0gJQMFZP+wV8Uud/0y0ETiIYAAi/mFM Ury27Bqlz6JcaubULMPZZzeo= X-Received: by 2002:a67:f591:: with SMTP id i17mr15477327vso.39.1574863672626; Wed, 27 Nov 2019 06:07:52 -0800 (PST) X-Google-Smtp-Source: APXvYqxlkVyEQhgupfQdCWxS2Yso56m4OHRUhrNQ7xkATgcfMymuExFxGn+Fjp4yNR/HpbE5l8pY9iStxfjJ7J2kXVI= X-Received: by 2002:a67:f591:: with SMTP id i17mr15477300vso.39.1574863672272; Wed, 27 Nov 2019 06:07:52 -0800 (PST) MIME-Version: 1.0 References: <20191127134213.9003-1-thomas@monjalon.net> <237226cc-c734-2386-273b-f86fe4c829ef@intel.com> In-Reply-To: <237226cc-c734-2386-273b-f86fe4c829ef@intel.com> From: David Marchand Date: Wed, 27 Nov 2019 15:07:41 +0100 Message-ID: To: Ferruh Yigit Cc: Thomas Monjalon , Matan Azrad , Shahaf Shuler , Viacheslav Ovsiienko , Jasvinder Singh , Cristian Dumitrescu , Andrew Rybchenko , dev , dpdk stable , Raslan Darawsheh X-MC-Unique: uJx9HoulMkSvkq_nc9Ycfg-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: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. --=20 David Marchand