On Dec 16, 2013, at 10:36 PM, Jarno Rajahalme <jrajaha...@nicira.com> wrote:
> 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. > I just noticed you acked these, thanks! Jarno > 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
