On Aug 18, 2011, at 4:15 AM, Jesse Gross wrote:
> On Aug 18, 2011 12:21 AM, "Ben Pfaff" <b...@nicira.com> wrote:
> >
> > [bringing Neil McKee into the conversation since he knows more about
> > this than me]
> >
> > On Wed, Aug 17, 2011 at 02:17:03PM +0800, Jesse Gross wrote:
> > > The one piece that I'm the least sure of is how to handle stats. In
> > > my ideal world, we would drop the sample pool altogether and have
> > > userspace figure it out for itself. The information is clearly
> > > present in userspace to calculate any packet count that may be
> > > required but it might not be instantaneously accurate. I'm unsure of
> > > the consequences of this. I think it's reasonable to report some kind
> > > of stats (current flow stats seems to fit) but if you're trying to get
> > > the current port counters then that isn't really useful. Directly
> > > reporting port count seems a little out of place to me. Ben, (or
> > ^^^^^^^^^ packet count?
>
> Yes, sorry, I meant packet count on the port (as opposed to the flow), which
> is essentially what the sample pool is.
>
> > > anyone else) do you have any thoughts?
> >
> > My understanding is that the sflow sample pool should be
> > asymptotically correct, that is, it should be within O(1) of the
> > correct value as n increases to infinity. So I think that it's OK if
> > the stats are always instantaneously behind a bit.
>
> OK, I buy that and it means that userspace already has all the information it
> needs.
Yes, if you are certain that the counters available in user-space are never
incremented in a place where the current sample pool would not be (or
vice-versa) then you could eliminate that atomic_inc() step from the datapath.
However since execute_actions() is called in two places it seems like this
might be quite hard to verify for all cases(?)
Another check worth confirming is that the random number generator you are
using will always converge exactly to the intended 1-in-N mean (before too
long). That gives you another fall-back position.
Neil
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
