[ovs-dev] [PATCH 06/12] dpif: Meter framework.

Ben Pfaff blp at nicira.com
Tue Nov 12 05:03:03 UTC 2013


On Tue, Nov 12, 2013 at 09:19:59AM +0800, Jesse Gross wrote:
> On Tue, Nov 12, 2013 at 7:53 AM, Ben Pfaff <blp at nicira.com> wrote:
> > On Fri, Nov 08, 2013 at 10:54:38AM -0800, Jarno Rajahalme wrote:
> >> Add DPIF-level support for meters. Allow meter_set to modify the meter
> >> configuration (e.g. set the burst size if unspecified).
> >> Summary:
> >
> > I think we need to get Jesse's view on the meter stuff.  I'll review
> > the userspace API, if you like, or if you think that a userspace-only
> > implementation would be useful, but we need his input to get it into
> > the kernel.
> 
> The concern that I have is that I think the actual meter
> implementation needs to be better integrated with the rest of the
> kernel in order to be upstreamable. I'm a little nervous about
> defining an API until we have at least one implementation that could
> be used in practice.
> 
> The other thing that I think would be good to talk about is how this
> relates to the existing QoS features and other possible ways that we
> might want to extend meters in the future.

I totally understand both of those concerns, and I'm on board with them.
Mostly I was hoping that since you sit closer to the kernel QoS stack
you'd have an idea for the kernel integration.

Let me try to advance the discussion then.

Maybe this is a "duh" kind of thing to other people, but I think that
what OpenFlow calls "metering" is what Linux calls "policing".  The
definitions, at least, are similar.  According to OpenFlow 1.3, a meter
measures the rate at which packets pass through it and either drops them
or changes their DSCP values.  According to the traffic control HOWTO,
"A policer will accept traffic to a certain rate, and then perform an
action on traffic exceeding this rate. A rather harsh solution is to
drop the traffic, although the traffic could be reclassified instead of
being dropped."

So a kernel action to invoke a policer would seem to be a place to
start.  I think we'd need the datapath module to maintain a table of
policers, probably identified by an integer value.  The action would
need to specify which one to invoke.

"Drop" meters/policers would be easier to deal with than remarking
meters/policers, because presumably recirculation is needed in the
general case where the dscp changes and later tables want to match on
the dscp.

Even "drop" meters/policers might be somewhat difficult, because I guess
that even if we "drop" along some path through the flow tables, we'd
still want to process anything along the "call stack" of resubmits.

In short it sounds nontrivial even if we have the policer building block
ready to go.  I'm not sure that it's worth it unless we have some
compelling use case.

Jarno?  Jesse?



More information about the dev mailing list