[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openvswitch-discuss
Subject:    [ovs-discuss] branch-2.3: rx/tx counter overflow
From:       blp () nicira ! com (Ben Pfaff)
Date:       2014-10-29 21:20:34
Message-ID: 20141029212034.GB10480 () nicira ! com
[Download RAW message or body]

On Wed, Oct 29, 2014 at 11:04:02PM +0400, Andrey Korolyov wrote:
> On Wed, Oct 29, 2014 at 6:56 PM, Ben Pfaff <blp at nicira.com> wrote:
> > On Tue, Oct 28, 2014 at 08:31:43AM -0700, Ben Pfaff 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 <blp at nicira.com> wrote:
> >> > > On Mon, Oct 27, 2014 at 9:15 AM, Andrey Korolyov <andrey at xdel.ru> wrote:
> >> > >> On Mon, Oct 27, 2014 at 7:15 PM, Ben Pfaff <blp at 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 <blp at 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 <blp at 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.
> >
> > I sent out a fix:
> >         http://openvswitch.org/pipermail/dev/2014-October/047940.html
> > Would you mind testing that it solves your problem?
> 
> 
> Thanks, worked perfectly! By the way, patchwork status is a bit
> outdated (last commit was fetched from ml six days ago).

I'm glad it fixed the problem.

We're aware something is wrong with patchwork.  We'll try to fix it.

[prev in list] [next in list] [prev in thread] [next in thread]