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