From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 0CEE54CE6 for ; Fri, 15 Apr 2016 11:11:30 +0200 (CEST) Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214] helo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1aqzoR-000552-MK; Fri, 15 Apr 2016 11:13:16 +0200 From: Olivier Matz To: "Wiles, Keith" References: <1458576484-28211-1-git-send-email-olivier.matz@6wind.com> <024DB49E-56E0-4550-A981-00CE20E6A23D@intel.com> <56F11503.8060905@6wind.com> Cc: "dev@dpdk.org" , "adrien.mazarguil@6wind.com" , Thomas Monjalon , yongwang@vmware.com Message-ID: <5710B037.10607@6wind.com> Date: Fri, 15 Apr 2016 11:11:19 +0200 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: Content-Type: text/plain; charset=utf-8 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: Fri, 15 Apr 2016 09:11:30 -0000 Hi, On 03/22/2016 03:27 PM, Wiles, Keith wrote: > Hi Olivier, > >> 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. > > Well I guess I must agree with the solution, but I am not real happy. Can we mark this a temp fix until we figure out a cleaner solution as I would not want this type of solution forever or be the standard way to handle these problems. Back on this issue, I agree that a cleaner solution may be needed, probably in the ethdev API. I did a quick look in the drivers directory and, from what I remember, vmxnet3 also need to have a number of rxq and txq to be a power of 2. >>From what I see in the code, if an application tries to configure a number of queue which is not a power of 2 on vmxnet3, the driver will fail to start without any log. Yong, do you feel a patch similar to what was done on mlx4 is feasable/suitable in vmxnet3 driver? Shouldn't at least have some error logs saying that the number of rxq/txq is invalid? It cleanup or rework is planned in the ethdev API for 16.11, maybe this is a problem that should be addressed. Regards, Olivier