doc: announce changes to rte_eth_set_queue_rate_limit api

  From: Satha Rao <skoteshwar@marvell.com>

rte_eth_set_queue_rate_limit argument rate modified to uint64_t
to support more than 64Gbps.

Signed-off-by: Satha Rao <skoteshwar@marvell.com>
---
 doc/guides/rel_notes/deprecation.rst | 5 +++++
 1 file changed, 5 insertions(+)
  

On 7/1/22 18:32, skoteshwar@marvell.com wrote:
> From: Satha Rao <skoteshwar@marvell.com>
> 
> rte_eth_set_queue_rate_limit argument rate modified to uint64_t
> to support more than 64Gbps.
> 
> Signed-off-by: Satha Rao <skoteshwar@marvell.com>
> ---
>   doc/guides/rel_notes/deprecation.rst | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 4e5b23c..5bf2b72 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -125,3 +125,8 @@ Deprecation Notices
>     applications should be updated to use the ``dmadev`` library instead,
>     with the underlying HW-functionality being provided by the ``ioat`` or
>     ``idxd`` dma drivers
> +
> +* ethdev: The function ``rte_eth_set_queue_rate_limit`` takes ``rate`` in Mbps.
> +  This parameter declared as uint16_t, queue rate limited to 64Gbps. ``rate``
> +  parameter will be modified to uint64_t in DPDK 22.11 so that it can work for
> +  more than 64Gbps.

I fully agree that uint16_t is not enough, but I'd like to understand
the reason behind uint64_t vs uint32_t. It looks like uint32_t is more
than enough.
  

-----Original Message-----
From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru> 
Sent: Thursday, July 7, 2022 6:23 PM
To: Satha Koteswara Rao Kottidi <skoteshwar@marvell.com>; Ray Kinsella <mdr@ashroe.eu>
Cc: dev@dpdk.org
Subject: [EXT] Re: [PATCH] doc: announce changes to rte_eth_set_queue_rate_limit api

External Email

----------------------------------------------------------------------
On 7/1/22 18:32, skoteshwar@marvell.com wrote:
> From: Satha Rao <skoteshwar@marvell.com>
> 
> rte_eth_set_queue_rate_limit argument rate modified to uint64_t to 
> support more than 64Gbps.
> 
> Signed-off-by: Satha Rao <skoteshwar@marvell.com>
> ---
>   doc/guides/rel_notes/deprecation.rst | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst 
> b/doc/guides/rel_notes/deprecation.rst
> index 4e5b23c..5bf2b72 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -125,3 +125,8 @@ Deprecation Notices
>     applications should be updated to use the ``dmadev`` library instead,
>     with the underlying HW-functionality being provided by the ``ioat`` or
>     ``idxd`` dma drivers
> +
> +* ethdev: The function ``rte_eth_set_queue_rate_limit`` takes ``rate`` in Mbps.
> +  This parameter declared as uint16_t, queue rate limited to 64Gbps. 
> +``rate``
> +  parameter will be modified to uint64_t in DPDK 22.11 so that it can 
> +work for
> +  more than 64Gbps.

I fully agree that uint16_t is not enough, but I'd like to understand the reason behind uint64_t vs uint32_t. It looks like uint32_t is more than enough.

>> yes uint32_t is enough, proposed uint64_t so that the rate in TM shaper profile is also uint64_t in bps
  

Hi Andrew,

Are you convinced with my response, or you want me to change this field to uint32_t?

Thanks,
Satha.

-----Original Message-----
From: Satha Koteswara Rao Kottidi <skoteshwar@marvell.com> 
Sent: Thursday, July 7, 2022 7:09 PM
To: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>; Ray Kinsella <mdr@ashroe.eu>
Cc: dev@dpdk.org
Subject: RE: [EXT] Re: [PATCH] doc: announce changes to rte_eth_set_queue_rate_limit api



-----Original Message-----
From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Sent: Thursday, July 7, 2022 6:23 PM
To: Satha Koteswara Rao Kottidi <skoteshwar@marvell.com>; Ray Kinsella <mdr@ashroe.eu>
Cc: dev@dpdk.org
Subject: [EXT] Re: [PATCH] doc: announce changes to rte_eth_set_queue_rate_limit api

External Email

----------------------------------------------------------------------
On 7/1/22 18:32, skoteshwar@marvell.com wrote:
> From: Satha Rao <skoteshwar@marvell.com>
> 
> rte_eth_set_queue_rate_limit argument rate modified to uint64_t to 
> support more than 64Gbps.
> 
> Signed-off-by: Satha Rao <skoteshwar@marvell.com>
> ---
>   doc/guides/rel_notes/deprecation.rst | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index 4e5b23c..5bf2b72 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -125,3 +125,8 @@ Deprecation Notices
>     applications should be updated to use the ``dmadev`` library instead,
>     with the underlying HW-functionality being provided by the ``ioat`` or
>     ``idxd`` dma drivers
> +
> +* ethdev: The function ``rte_eth_set_queue_rate_limit`` takes ``rate`` in Mbps.
> +  This parameter declared as uint16_t, queue rate limited to 64Gbps. 
> +``rate``
> +  parameter will be modified to uint64_t in DPDK 22.11 so that it can 
> +work for
> +  more than 64Gbps.

I fully agree that uint16_t is not enough, but I'd like to understand the reason behind uint64_t vs uint32_t. It looks like uint32_t is more than enough.

>> yes uint32_t is enough, proposed uint64_t so that the rate in TM 
>> shaper profile is also uint64_t in bps
  

07/07/2022 15:38, Satha Koteswara Rao Kottidi:
> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru> 
> > On 7/1/22 18:32, skoteshwar@marvell.com wrote:
> > > +* ethdev: The function ``rte_eth_set_queue_rate_limit`` takes ``rate``
> > > in Mbps. +  This parameter declared as uint16_t, queue rate limited to
> > > 64Gbps. +``rate``
> > > +  parameter will be modified to uint64_t in DPDK 22.11 so that it can
> > > +work for
> > > +  more than 64Gbps.
> > 
> > I fully agree that uint16_t is not enough, but I'd like to understand the
> > reason behind uint64_t vs uint32_t. It looks like uint32_t is more than
> > enough.

> yes uint32_t is enough, proposed uint64_t so that the rate in TM shaper profile is also uint64_t in bps

I don't see how both are related.
Why not stick to uint32_t for this parameter?

Also I'm not sure it is breakage.
If it was, it could have been handled with function versioning.
But anyway it is a small change, I am OK with uint32_t.
  

Thanks Thomas. I will send v2 with uint32_t type.

Thanks,
Satha.

-----Original Message-----
From: Thomas Monjalon <thomas@monjalon.net> 
Sent: Tuesday, July 12, 2022 7:34 PM
To: Satha Koteswara Rao Kottidi <skoteshwar@marvell.com>
Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>; Ray Kinsella <mdr@ashroe.eu>; dev@dpdk.org; ferruh.yigit@amd.com; bruce.richardson@intel.com; konstantin.v.ananyev@yandex.ru; ajit.khaparde@broadcom.com; Jerin Jacob Kollanukkaran <jerinj@marvell.com>
Subject: Re: [EXT] Re: [PATCH] doc: announce changes to rte_eth_set_queue_rate_limit api

07/07/2022 15:38, Satha Koteswara Rao Kottidi:
> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> > On 7/1/22 18:32, skoteshwar@marvell.com wrote:
> > > +* ethdev: The function ``rte_eth_set_queue_rate_limit`` takes 
> > > +``rate``
> > > in Mbps. +  This parameter declared as uint16_t, queue rate 
> > > limited to 64Gbps. +``rate``
> > > +  parameter will be modified to uint64_t in DPDK 22.11 so that it 
> > > +can work for
> > > +  more than 64Gbps.
> > 
> > I fully agree that uint16_t is not enough, but I'd like to 
> > understand the reason behind uint64_t vs uint32_t. It looks like 
> > uint32_t is more than enough.

> yes uint32_t is enough, proposed uint64_t so that the rate in TM 
> shaper profile is also uint64_t in bps

I don't see how both are related.
Why not stick to uint32_t for this parameter?

Also I'm not sure it is breakage.
If it was, it could have been handled with function versioning.
But anyway it is a small change, I am OK with uint32_t.