On Mon, Nov 11, 2013 at 09:03:03PM -0800, Ben Pfaff wrote: > On Tue, Nov 12, 2013 at 09:19:59AM +0800, Jesse Gross wrote: > > On Tue, Nov 12, 2013 at 7:53 AM, Ben Pfaff <b...@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?
Jarno, I didn't ever see any further discussion on this. I'm trying to clean up patchwork, so I marked patches 6-12 in this series as Deferred. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
