On Mon, Jul 1, 2013 at 8:32 AM, Rajahalme, Jarno (NSN - FI/Espoo) <jarno.rajaha...@nsn.com> wrote: > > On Jun 29, 2013, at 0:59 , ext Jesse Gross wrote: > >> On Fri, Jun 28, 2013 at 10:50 AM, Ben Pfaff <b...@nicira.com> wrote: >>> On Thu, Jun 27, 2013 at 01:39:52AM +0300, Jarno Rajahalme wrote: >>>> >>>> Signed-off-by: Jarno Rajahalme <jarno.rajaha...@nsn.com> >>>> --- >>>> v2: Remove resetting of provider meter id on failure in dpif_meter_set(). >>> >>> Changes to <linux/openvswitch.h> need Jesse's approval, so I'm handing >>> this over to him. >> >> I think the implementation (or at least a high level design) needs to >> be fleshed out first. Adding a new QoS implementation is not going to >> be upstreamable, so we need to figure out how it fits together with >> the rest of the kernel and existing OVS QoS. > > Agree. I have a simple implementation for the userspace datapath in the > series for reference. A new netlink interface for managing the meter entries > is needed, and then the action type to refer to those meters from the kernel > flow entries. > > Obviously it would be preferable to use existing kernel facilities for the > implementation of the meters themselves. Do you know if, e.g., tc Token > Bucket Filter can be used per flow? That is, packet classification is already > done, just need to apply the filter and come up with drop/no-drop decision, > for each packet separately.
This is pretty similar to what we're doing currently with shaping: the actual shapers are configured directly through tc using the existing Netlink interfaces and then OVS sets the skb priority or mark based on its own classification. I think this type of integration is ideal although it's less clear how it would work for meters in the middle of the pipeline. X-CudaMail-Whitelist-To: dev@openvswitch.org _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
