Thanks Thomas. I will send v2 with uint32_t type. Thanks, Satha.
-----Original Message----- From: Thomas Monjalon <tho...@monjalon.net> Sent: Tuesday, July 12, 2022 7:34 PM To: Satha Koteswara Rao Kottidi <skotesh...@marvell.com> Cc: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru>; Ray Kinsella <m...@ashroe.eu>; dev@dpdk.org; ferruh.yi...@amd.com; bruce.richard...@intel.com; konstantin.v.anan...@yandex.ru; ajit.khapa...@broadcom.com; Jerin Jacob Kollanukkaran <jer...@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.rybche...@oktetlabs.ru> > > On 7/1/22 18:32, skotesh...@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.
