On Wed, Nov 27, 2019 at 3:11 PM Thomas Monjalon <tho...@monjalon.net> wrote: > > 27/11/2019 15:07, David Marchand: > > On Wed, Nov 27, 2019 at 3:06 PM Ferruh Yigit <ferruh.yi...@intel.com> 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. > > 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
