Thanks Thomas. I will send v2 with uint32_t type. Thanks, Satha.
-----Original Message----- From: Thomas Monjalon <[email protected]> Sent: Tuesday, July 12, 2022 7:34 PM To: Satha Koteswara Rao Kottidi <[email protected]> Cc: Andrew Rybchenko <[email protected]>; Ray Kinsella <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Jerin Jacob Kollanukkaran <[email protected]> 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 <[email protected]> > > On 7/1/22 18:32, [email protected] 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.
