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 <olivier.matz at 6wind.com> >>>> 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
