> -----Original Message----- > From: Stokes, Ian <[email protected]> > Sent: Wednesday, July 7, 2021 3:38 PM > To: Eelco Chaudron <[email protected]>; Van Haaren, Harry > <[email protected]>; Amber, Kumar <[email protected]> > Cc: Amber, Kumar <[email protected]>; Ferriter, Cian > <[email protected]>; [email protected]; [email protected]; > [email protected] > Subject: RE: [v6 00/11] MFEX Infrastructure + Optimizations > > > On 7 Jul 2021, at 12:13, Van Haaren, Harry wrote: > > > > > Hi All, > > > > > > This thread has dissolved into unnecessary time-wasting on nitpick > > > changes. > > There is no > > > technical issue with uint32_t, so this patch remains as is, and this > > > should be > > accepted for merge. > > > > > > If you feel differently, reply to this with a detailed description of a > > > genuine > > technical bug. > > > > Reviews are not only about technical correctness but also about coding style > > and consistency. > > In this case the dp_packet_batch_size() API returns a size_t, so we should > > try > to > > use it. > > > +1
OK, lets work on a viable solution that OVS build-system & the compilers support. > > But I leave it to the maintainers to decide if they accept this as is, or > > not :) > > If the standard is to use size_t then I believe we should stick with that. I > think it's > a separate conversation with regards to if size_t should be used and is best > for > the dp_packet_batch_size API and probably beyond the scope of this patch > series. Agree that it's beyond scope of patchset. > For the moment I'd prefer to see a solution using size_t. OK, based on coding-style.rst, the PRIuSIZE format spec. will be used. > Regards > Ian > > > //Eelco Thanks for input all. <snip> _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
