14:03:46 <ajo> #startmeeting neutron_qos
14:03:47 <openstack> Meeting started Wed Mar 23 14:03:46 2016 UTC and is due to finish in 60 minutes.  The chair is ajo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:03:51 <openstack> The meeting name has been set to 'neutron_qos'
14:03:52 <jschwarz> njohnsto_, did you see the mail tread I opened for you? :)
14:04:11 <njohnsto_> Yes, and I am very much appreciative!
14:05:06 <njohnsto_> jschwarz: I'll get the hang of full stack tests yet; I'm just glad I wasn't doing something foolish.
14:05:16 <ajo> hi :-)ok, let's get to that at some point :D
14:05:26 <ajo> #topic Features: DSCP
14:05:43 <jschwarz> :)
14:05:50 <ajo> DSCP got merged for Newton, sadly not for Mitaka, but life goes on,
14:06:07 <ajo> I'm happy to see it finally merged.
14:06:17 <davidsha> +1
14:06:18 <njohnsto_> Hallelujah and amen
14:06:22 <ajo> lol
14:06:55 <njohnsto_> The docs changes are waiting for the Newton cut offs
14:07:17 <ajo> Technologies like SR-IOV support that, and OVS & Linux bridge can be configured to support this type of service. Where in OvS it requires to
14:07:17 <ajo> We will have to wait for the dependencies also to finish the fullstack part
14:08:09 <ajo> (aka python-neutronclient)
14:08:15 <njohnsto_> Yes
14:08:24 <ajo> njohnsto_, you're tracking the docs, right?
14:24:02 <ajo> reedip__ not exactly, I mean, how would it work exactly
14:24:09 <ajo> it's more like an spec what I'm asking probably
14:24:11 <reedip__> ajo , ok
14:24:31 <ajo> so I wonder if you could just jump into the spec, may be in etherpad format until drivers give you approval
14:25:21 <ajo> because from vikram conversation
14:25:44 <reedip__> ajo : Yes, I think I can start the spec on etherpad, and then discuss the same with the drivers in a seprate thread
14:25:44 <ajo> I understood that you could use the ECN signaling from node to node to throttle the other side bandwidth in OVS
14:25:50 <ajo> when ECN is supposed to be E2E
14:27:13 <ajo> ok, we can wait for that, and move on now.
14:27:27 <ajo> #topic Bugs
14:27:39 <ajo> #link https://bugs.launchpad.net/neutron/+bug/1507761 qos wrong units in max-burst-kbps option (per-second is wrong)
14:27:48 <ajo> ah, I see slawek is not here
14:27:50 <openstack> Launchpad bug 1507761 in neutron "qos wrong units in max-burst-kbps option (per-second is wrong)" [Low,In progress] - Assigned to Slawek Kaplonski (slaweq)
14:27:52 <ajo> I remember he started work on it
14:28:45 <ajo> but I see no review linked
14:28:46 <ajo> ok
14:28:50 <ajo> #topic Free discussion
14:29:01 <ajo> anything that I missed or anybody wants to discuss? :)
14:29:24 <davidsha> #link https://review.openstack.org/#/c/291633/
14:29:57 <ajo> thanks davidsha , I will manually add it to the bug report.
14:30:09 <davidsha> ajo: np :)
14:30:34 * njohnsto_ is copacetic.
14:31:28 <davidsha> just on neutron classifier, is there a way we could make it use OVS flows? the only way I can think of is to pass in the bridge object, otherwise would it be worth just using it with tc?
14:32:00 <ajo> davidsha, that's a good question, also related to min bw guarantees
14:32:24 <ajo> so the most "compatible" way with our current openflow rules would be using tc to filter / queue stuff
14:32:29 <ajo> but it's a bit of a mix up
14:32:32 <ajo> please look at this review
14:32:49 <ajo> https://review.openstack.org/#/c/284259/13/doc/source/devref/openvswitch_firewall.rst
14:32:59 <ajo> this is being implemented for jlibosva in the ovs firewall
14:33:14 <ajo> it marks the port number in reg5 and local-vlan on reg6
14:33:28 <ajo> we could use that to avoid the "NORMAL" rules for data, and use directed flows
14:34:47 <davidsha> kk, I'm going to be working on the extension-flow management as well so I'll keep an eye on this.
14:34:50 <ajo> if we had directed flows for the traffic (instead of using NORMAL to send the packet finally to it's destination) we could just use enqueue(port, queue)
14:35:24 <ajo> I wonder if we could use the set_queue action
14:35:26 <ajo> at some point
14:35:51 <ajo> I didn't look at that when I experimented
14:36:00 <ajo> set_queue:queue
14:36:00 <ajo> Sets the queue that should be used to queue when packets are output.   The  number  of  supported  queues
14:36:00 <ajo> depends on the switch; some OpenFlow implementations do not support queuing at all.
14:36:04 <ajo> I wonder if that works with "NORMAL"
14:36:10 <ajo> davidsha, ^  any idea?
14:36:29 <davidsha> I'm unfamiliar with set_queue, I'll look into it. Also enqueue doesn't actually send the traffic so it can still be resubmitted!
14:36:51 <ajo> davidsha, it does not?
14:37:28 <davidsha> ajo: no, I'll double check but last time I used it it didn't send packets unless I included the Normal action.
14:37:41 <ajo> davidsha, it worked in my experiments
14:37:46 <ajo> without the normal action, of course :)
14:38:17 <davidsha> I'll double check later, it's probably my mistake then.
14:38:31 <ajo> davidsha, : https://github.com/mangelajo/ovs-experiments/blob/master/qos/qos_complex_traffic_shapping.sh#L298
14:38:56 <ajo> if we could use dl_dst=$MAC_A actions=set_queue:N
14:39:05 <ajo> and then NORMAL obeys that... that'd be awesome
14:39:52 <ajo> #action ajo try set_queue to see if it's a way to simplify how to implement traffic_classification and min bandwidth
14:40:07 <davidsha> was the traffic being received though?
14:40:34 <ajo> davidsha, yes
14:40:51 <ajo> davidsha, and the bandwidth measurements matched what it was expected
14:41:30 <ajo> davidsha, you can run the script in your machine if you want :)
14:41:46 <ajo> davidsha, it cleans up at the end.
14:42:29 <davidsha> kk, I think you showed it to me before as well, I'll try it again.
14:43:01 <ajo> ok, anything else, or shall we end the meeting for today? :)
14:45:34 <davidsha> I'm good, thanks!
14:46:33 <ajo> soo
14:46:36 <ajo> thanks everybody for joining
14:46:48 <ajo> #endmeeting