> On Jan 11, 2016, at 9:35 AM, Ben Pfaff <b...@ovn.org> wrote: > > 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 <b...@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? >>
I see I only looked at the OpenFlow spec (pre 1.5) and did not consider the interaction with resubmits. >> 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. I see that OpenFlow 1.5 changed the specification for meters (from an instruction to an action, allowing multiple meters per flow entry). I’ll have a look at the implications. The relevant actions after the meter should probably be encapsulated and executed only if the meter does not drop. We do have precedence for encapsulated actions in the sample action, so it should not be too weird. Jarno _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
