ethdev: limit maximum number of queues

  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.

Fixes: 7fae69eeff13 ("mlx4: new poll mode driver")
Fixes: e60fbd5b24fc ("mlx5: add device configure/start/stop")
Fixes: cc6d421574fe ("net/softnic: add softnic PMD")
Fixes: 9e6b36c34ce9 ("app/testpmd: reduce memory consumption")
Cc: stable@dpdk.org

Reported-by: Raslan Darawsheh <rasland@mellanox.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
 drivers/net/mlx4/mlx4_ethdev.c        | 4 +---
 drivers/net/mlx5/mlx5_ethdev.c        | 4 +---
 drivers/net/softnic/rte_eth_softnic.c | 4 ++--
 lib/librte_ethdev/rte_ethdev.c        | 6 ++++++
 4 files changed, 10 insertions(+), 8 deletions(-)
  

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?

> 
> Fixes: 7fae69eeff13 ("mlx4: new poll mode driver")
> Fixes: e60fbd5b24fc ("mlx5: add device configure/start/stop")
> Fixes: cc6d421574fe ("net/softnic: add softnic PMD")
> Fixes: 9e6b36c34ce9 ("app/testpmd: reduce memory consumption")
> Cc: stable@dpdk.org
> 
> Reported-by: Raslan Darawsheh <rasland@mellanox.com>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
>  drivers/net/mlx4/mlx4_ethdev.c        | 4 +---
>  drivers/net/mlx5/mlx5_ethdev.c        | 4 +---
>  drivers/net/softnic/rte_eth_softnic.c | 4 ++--
>  lib/librte_ethdev/rte_ethdev.c        | 6 ++++++
>  4 files changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/net/mlx4/mlx4_ethdev.c b/drivers/net/mlx4/mlx4_ethdev.c
> index dfb24c22d0..a18a66cb4a 100644
> --- a/drivers/net/mlx4/mlx4_ethdev.c
> +++ b/drivers/net/mlx4/mlx4_ethdev.c
> @@ -646,9 +646,7 @@ mlx4_dev_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *info)
>  	 */
>  	max = ((priv->device_attr.max_cq > priv->device_attr.max_qp) ?
>  	       priv->device_attr.max_qp : priv->device_attr.max_cq);
> -	/* If max >= 65535 then max = 0, max_rx_queues is uint16_t. */
> -	if (max >= 65535)
> -		max = 65535;
> +	max = RTE_MIN(max, (unsigned int)RTE_MAX_QUEUES_PER_PORT);
>  	info->max_rx_queues = max;
>  	info->max_tx_queues = max;
>  	info->max_mac_addrs = RTE_DIM(priv->mac);
> diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
> index d80ae458bc..045dae6b5a 100644
> --- a/drivers/net/mlx5/mlx5_ethdev.c
> +++ b/drivers/net/mlx5/mlx5_ethdev.c
> @@ -617,9 +617,7 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *info)
>  	 */
>  	max = RTE_MIN(priv->sh->device_attr.orig_attr.max_cq,
>  		      priv->sh->device_attr.orig_attr.max_qp);
> -	/* If max >= 65535 then max = 0, max_rx_queues is uint16_t. */
> -	if (max >= 65535)
> -		max = 65535;
> +	max = RTE_MIN(max, (unsigned int)RTE_MAX_QUEUES_PER_PORT);
>  	info->max_rx_queues = max;
>  	info->max_tx_queues = max;
>  	info->max_mac_addrs = MLX5_MAX_UC_MAC_ADDRESSES;
> diff --git a/drivers/net/softnic/rte_eth_softnic.c b/drivers/net/softnic/rte_eth_softnic.c
> index 11723778fd..1065cbf847 100644
> --- a/drivers/net/softnic/rte_eth_softnic.c
> +++ b/drivers/net/softnic/rte_eth_softnic.c
> @@ -91,8 +91,8 @@ pmd_dev_infos_get(struct rte_eth_dev *dev __rte_unused,
>  	struct rte_eth_dev_info *dev_info)
>  {
>  	dev_info->max_rx_pktlen = UINT32_MAX;
> -	dev_info->max_rx_queues = UINT16_MAX;
> -	dev_info->max_tx_queues = UINT16_MAX;
> +	dev_info->max_rx_queues = RTE_MAX_QUEUES_PER_PORT;
> +	dev_info->max_tx_queues = RTE_MAX_QUEUES_PER_PORT;
>  
>  	return 0;
>  }
> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
> index 8d2ce31a81..6e9cb243ea 100644
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> @@ -2986,6 +2986,12 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
>  		return eth_err(port_id, diag);
>  	}
>  
> +	/* Maximum number of queues should be <= RTE_MAX_QUEUES_PER_PORT */
> +	dev_info->max_rx_queues = RTE_MIN(dev_info->max_rx_queues,
> +			RTE_MAX_QUEUES_PER_PORT);
> +	dev_info->max_tx_queues = RTE_MIN(dev_info->max_tx_queues,
> +			RTE_MAX_QUEUES_PER_PORT);
> +
>  	dev_info->driver_name = dev->device->driver->name;
>  	dev_info->nb_rx_queues = dev->data->nb_rx_queues;
>  	dev_info->nb_tx_queues = dev->data->nb_tx_queues;
>
  

On Wed, Nov 27, 2019 at 3:06 PM Ferruh Yigit <ferruh.yigit@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.
  

27/11/2019 15:07, David Marchand:
> On Wed, Nov 27, 2019 at 3:06 PM Ferruh Yigit <ferruh.yigit@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.

I can change if you feel strong about it.
  

On 11/27/2019 2:11 PM, Thomas Monjalon wrote:
> 27/11/2019 15:07, David Marchand:
>> On Wed, Nov 27, 2019 at 3:06 PM Ferruh Yigit <ferruh.yigit@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.
> 
> I can change if you feel strong about it.
> 

No strong opinion, but not sure if we should document ethdev limitation in
ethdev, for me only ethdev limit looks good.
  

On 11/27/2019 2:14 PM, Ferruh Yigit wrote:
> On 11/27/2019 2:11 PM, Thomas Monjalon wrote:
>> 27/11/2019 15:07, David Marchand:
>>> On Wed, Nov 27, 2019 at 3:06 PM Ferruh Yigit <ferruh.yigit@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.
>>
>> I can change if you feel strong about it.
>>
> 
> No strong opinion, but not sure if we should document ethdev limitation in
> ethdev, for me only ethdev limit looks good.
> 

... not sure if we should document ethdev limitation in *PMD* ...
  

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