From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id 855352904 for ; Tue, 22 Mar 2016 10:48:54 +0100 (CET) Received: by mail-wm0-f52.google.com with SMTP id l68so143848597wml.0 for ; Tue, 22 Mar 2016 02:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=qDdSEU3eLT68+9gevUtfCYV1G0UMC270TqIa/e2lW2E=; b=W9YpmwyaEkd8irkht3VtS/6/moOyTvsmdOmHmpPkTDKv4mPazEyjif6HbsyIDaYpTr ZQ0LeszLMIwVWkNnr3YLofeVXBr8uMZVpZcjufH0BQ61CecO4X3VAnwuvq+93YPQkEOc hV1S4+uEe3uTzzQJbJwYUx7LTM0eFTLJjpPyyp+T4/UtOQKIzAmZW/gkF/WToiErVTLu haF0Tdzw2oiscT4bv3bLoMHT7Fv9w0UlUJO2+6U/Jw7+WrR8xz3y8RbjJeLzwtA4iVxZ 5yj8dyRmBRy5nvHxDCHzqTEH5rig0xusYENewcf85e8OJhHrEoIjDB7wyQ7e1c/vEsiH 6Hog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=qDdSEU3eLT68+9gevUtfCYV1G0UMC270TqIa/e2lW2E=; b=fi1l3xN7dE86TdgxfqHPM2U2U2CTRDpgrA72XTjFUX9c7+vtlF1uv7NxsEnEYkTBT5 keilvmmBNLZQ1eOCX9hLzXumkogj7GaseOwUepPbbUri+eORatSJjMfhxfDo9T/P7sit L02kRWvgNfb51FwcbteeL5bu/5Nnw9ZD60b3fKt7YkAh1vXndpbRAqvsHhP7cb1YSNIr e6qCyWLswarvdGrqqQUuNGq+aKDcbC7hbtSYRnoou2hFXSkY3hxObFW2zCELrbxezR8f P+0lfyQW0EOUy6RCcqfBmRIwFk5CYBvWKwoK0Ee6BMkdhW9NZU3dlqm8ar0H45h9m0AX DIog== X-Gm-Message-State: AD7BkJLW3dlQXUQxFRjrdL8ZlvJmRZwfs6FSRxuJYnM9m6pMlnOB/NofhFnzcYMnBLsl/A+K X-Received: by 10.28.55.74 with SMTP id e71mr19948668wma.26.1458640134382; Tue, 22 Mar 2016 02:48:54 -0700 (PDT) Received: from [192.168.0.10] (was59-1-82-226-113-214.fbx.proxad.net. [82.226.113.214]) by smtp.gmail.com with ESMTPSA id g3sm29429545wjw.31.2016.03.22.02.48.53 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Mar 2016 02:48:53 -0700 (PDT) To: "Wiles, Keith" References: <1458576484-28211-1-git-send-email-olivier.matz@6wind.com> <024DB49E-56E0-4550-A981-00CE20E6A23D@intel.com> Cc: "dev@dpdk.org" , "adrien.mazarguil@6wind.com" From: Olivier Matz Message-ID: <56F11503.8060905@6wind.com> Date: Tue, 22 Mar 2016 10:48:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 MIME-Version: 1.0 In-Reply-To: <024DB49E-56E0-4550-A981-00CE20E6A23D@intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] mlx4: use dummy rxqs when a non-pow2 number is requested X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 09:48:54 -0000 Hi Keith, On 03/21/2016 06:38 PM, Wiles, Keith wrote: >> On Mar 21, 2016, at 11:10 AM, Olivier Matz wrote: >> >> When using RSS, the number of rxqs has to be a power of two. >> This is a problem because there is no API is dpdk that makes >> the application aware of that. >> >> A good compromise is to allow the application to request a >> number of rxqs that is not a power of 2, but having inactive >> queues that will never receive packets. In this configuration, >> a warning will be issued to users to let them know that >> this is not an optimal configuration. > > Not sure I like this solution. I think an error should be returned with a log message instead. What if the next driver needs power of three or must be odd or even number. > > The bigger problem is the application is no longer portable for any given nic configuration. > > We need a method for the application to query the system for these types of information. But as we do not have that API we need to just error the request off. The initial problem is that the driver says "I support a maximum of X queues" and if the application configures a lower number, it gets an error. There is no API in DPDK to tell that only specific number of queues are supported. Adding an API is a solution, but in this case it's probably overkill. With this patch, the driver can present the proper number of queues to the application, knowing that the spreading of the packets won't be ideal (some queues won't receive packets), but it will work. A step further in this direction would be to configure more queues than asked in hardware to do a better spreading, almost similar to what is done with RETA tables in mlx5. But this is more complicated to do, especially if we want it for 16.04. Hope this is clearer with the explanation. Regards, Olivier