[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