On Tue, Oct 28, 2014 at 6:31 PM, Ben Pfaff <b...@nicira.com> wrote: > On Tue, Oct 28, 2014 at 03:37:58PM +0400, Andrey Korolyov wrote: >> On Mon, Oct 27, 2014 at 8:19 PM, Ben Pfaff <b...@nicira.com> wrote: >> > On Mon, Oct 27, 2014 at 9:15 AM, Andrey Korolyov <and...@xdel.ru> wrote: >> >> On Mon, Oct 27, 2014 at 7:15 PM, Ben Pfaff <b...@nicira.com> wrote: >> >>> On Mon, Oct 27, 2014 at 08:12:28PM +0400, Andrey Korolyov wrote: >> >>>> On Mon, Oct 27, 2014 at 7:09 PM, Ben Pfaff <b...@nicira.com> wrote: >> >>>> > On Mon, Oct 27, 2014 at 08:05:01PM +0400, Andrey Korolyov wrote: >> >>>> >> On Mon, Oct 27, 2014 at 7:04 PM, Ben Pfaff <b...@nicira.com> wrote: >> >>>> >> > On Mon, Oct 27, 2014 at 07:55:01PM +0400, Andrey Korolyov wrote: >> >>>> >> >> ovs-ofctl dump-ports currently reporting values not large than >> >>>> >> >> u32 in >> >>>> >> >> the mentioned branch. lib/ofp-util.c has no regressions at a >> >>>> >> >> glance, >> >>>> >> >> probably truncation going in the different (not so obvious) way. >> >>>> >> > >> >>>> >> > Are you using a 64-bit kernel? There is some unavoidable >> >>>> >> > truncation >> >>>> >> > with 32-bit kernels. >> >>>> >> >> >>>> >> Yes, of course. >> >>>> > >> >>>> > Thanks. I guess you must have previously seen 64-bit values with some >> >>>> > earlier version. Do you know what the most recent version was? >> >>>> >> >>>> For 0fe1d7f39de9836fea01c560a6fdbfd1405096ea it is clearly positive >> >>>> that it reports 64-bit counter values (branch-2.1). Had not tested >> >>>> against other revisions yet. Are you suggesting that the counter >> >>>> behavior with 32b limit is currently taken as a right one? >> >>> >> >>> I am trying to narrow down the range of commits that could have caused >> >>> the problem. "git bisect" would be the ideal way to do it, if you are >> >>> willing and able to try it. >> >> >> >> Heh, okay. I`m signing over bisection, please give me some time :) >> > >> > Thanks a lot. >> >> >> The bad cast introduced by 04c881eb6441fff2e91c9b9e23502bc554c0f437. > > That patch only adds assignments of 64-bit integers to 64-bit integers. > No casts or conversions are involved. > > Looking more closely, I think the problem here is that even 64-bit > kernels always pass IFLA_STATS to userspace using 32-bit integers. > Usersspace needs to look at IFLA_STATS64, instead, when it is present, > but there is currently no code to do that.
Thanks Ben. How big is an inaccuracy impact from calculation in a legacy (regarding to this patch) manner with enabled offloads, if you have such information? _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
