[ovs-dev] [PATCH v3 0/4] Meter implementation for userspace datapath.

Ben Pfaff blp at ovn.org
Mon Jan 11 17:35:17 UTC 2016


On Mon, Dec 21, 2015 at 11:38:33PM -0800, Ben Pfaff wrote:
> On Mon, Nov 30, 2015 at 10:03:11AM -0800, Jarno Rajahalme wrote:
> > 
> > > On Nov 29, 2015, at 17:12, Ben Pfaff <blp at ovn.org> wrote:
> > > 
> > >> On Mon, Nov 23, 2015 at 08:54:31PM -0800, Jarno Rajahalme wrote:
> > >> Back by popular demand, here is the OpenFlow meter implementation for
> > >> the userspace datapath.  Meters are inherently shared datapath
> > >> resources and this version uses a simple locking strategy which may
> > >> not be optimal for DPDK.  Nonetheless, this implementation should be a
> > >> good starting point for further optimizations.
> > > 
> > > OF1.5 has "drop" and "DSCP remark" meters.  It looks like this initial
> > > implementation has only "drop" meters.  Is it general enough that DSCP
> > > remarking meters could be supported later within the framework?
> > 
> > It should be, as remarking the packet is similar to a set action, but
> > drop meter requires the support for an datapath action dropping a
> > packet, which did not exist before.
> 
> OK.
> 
> The "meter" action as implemented by this series seems to be a "global"
> action, like "exit": if the meter drops the packet, then no later
> (datapath) action is executed.  But I think that would be surprising
> behavior: I would expect actions higher up on the control stack
> (e.g. from earlier "resubmit"s) to still get executed.  Did you consider
> any other techniques that could support that?
> 
> OpenFlow doesn't have much of a control stack, so it doesn't define this
> precisely, but OpenFlow 1.5 supports "egress tables" which have similar
> behavior: when a packet is output to a port like OFPP_FLOOD that
> actually corresponds to multiple ports, it passes separately through the
> egress tables for each of those ports, once for each of them.  The
> egress tables are allowed to use "meter" actions to drop packets, and
> although OpenFlow doesn't say so explicitly, I don't think it would make
> sense for this to drop every packet (or maybe just the ones that come
> later in processing order? (but the processing might happen in parallel
> anyway since it's hardware?)), instead of just the one egressing packet.

Do you have any thoughts?  It *would* be nice to get meters working,
since users sometimes ask about them.



More information about the dev mailing list