Ben, I have this series on a branch after these:
http://patchwork.openvswitch.org/patch/2157/ http://patchwork.openvswitch.org/patch/2158/ Applying the first needs some manual work due to a typo fix in a comment I made on the 1/3 of this series you acked earlier. After these two are in, I’ll send a rebased version of the meter framework, up to and including the userspace implementation, leaving the Linux kernel implementation for later work. Jarno On Dec 16, 2013, at 9:10 AM, Ben Pfaff <b...@nicira.com> wrote: > 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
