14:00:59 <njohnston> #startmeeting neutron_qos 14:01:00 <openstack> Meeting started Wed Jun 1 14:00:59 2016 UTC and is due to finish in 60 minutes. The chair is njohnston. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:04 <openstack> The meeting name has been set to 'neutron_qos' 14:01:08 <njohnston> All: I am having some trouble with my network; can someone else drive the meeting? I have the agenda laid out at https://etherpad.openstack.org/p/neutron_qos_meeting_chair 14:01:37 <njohnston> I am signed on from my iPhone which makes for poor typing and worse copy and paste 14:01:46 <ajo_> sure njohnston :) 14:01:50 <njohnston> #chair ajo_ 14:01:51 <openstack> Current chairs: ajo_ njohnston 14:02:25 <ajo_> not sure if the attendance is very high today :) 14:02:33 <davidsha> Hey 14:02:34 <ajo_> slaweq was not able to join 14:02:38 <ajo_> hi davidsha :) 14:02:39 <ajo_> nice 14:02:44 <ralonsoh> hello 14:03:04 <ajo_> hi ralonsoh :) 14:03:10 <ajo_> ping ihrachys :) 14:04:00 <ajo_> I will revert the order of bugs / RFEs if that works for you njohnston 14:04:13 <njohnston> By all means ajo_ 14:04:17 <ajo_> thanks :) 14:04:25 <ajo_> revert = invert 14:04:36 <ajo_> we have: 14:04:38 <ajo_> #topic Approved RFEs 14:04:38 <ajo_> #link http://tinyurl.com/qos-rfe-approved 14:05:05 <ajo_> a new approved RFE (min bandwidth egress on the hypervisor) :) 14:05:16 <ajo_> ralonsoh++ 14:05:21 <ralonsoh> working on it 14:05:23 <ajo_> and ihrachys++ as approver 14:05:30 <ralonsoh> I'll upload the last spec revision in one hour 14:05:53 <ajo_> regarding that, are you aware of the discussion around the ingress/egress direction field, and extended rule validation stuff? 14:06:02 <ralonsoh> yes 14:06:07 <ralonsoh> that's my question 14:06:14 <ralonsoh> there is nothing yet defined 14:06:18 <ajo_> ok, good, those are things that we can handle/switch at the last moment 14:06:27 <ajo_> before merging it, the change shall not be big 14:06:45 <ralonsoh> i'll upload only the changes for ovs 14:06:50 <ralonsoh> then LB and then sr-iov 14:06:55 <ajo_> For those not aware, we're talking about : 14:06:59 <hichihara> hi 14:07:01 <hichihara> I have a question about PoC for minimum bandwith. 14:07:04 <ajo_> #link https://bugs.launchpad.net/neutron/+bug/1586056 extended rule validation 14:07:04 <openstack> Launchpad bug 1586056 in neutron "[RFE] Improved validation mechanism for QoS rules with port types" [Wishlist,In progress] - Assigned to Slawek Kaplonski (slaweq) 14:07:08 <hichihara> I think that linux-htb must be set to patch-tun or int-br-<phys> in https://review.openstack.org/#/c/318531/2/neutron/plugins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py 14:07:11 <ajo_> hi hichihara go ahead :) 14:07:37 <ralonsoh> hichihara i made a comment 14:07:37 <hichihara> ajo_: what do you think? 14:07:58 <hichihara> ralonsoh: I saw it but I cannot agree 14:07:58 <ajo_> hichihara, patch-tun does not support htb/queues unless we convert it to a veth 14:08:02 <ralonsoh> ok 14:08:03 <ajo_> which is less performant. 14:08:10 <ajo_> but I haven't looked at the code details yet 14:08:21 <ajo_> hichihara, that's the way I did it on my experiments 14:08:27 <ajo_> something else that was suggested in the ovn/ovs list 14:08:45 <ajo_> is that we could create the queues in the physical interfaces which we have tunnel traffic going through 14:08:50 <hichihara> But each taps linux-htb really work fine? 14:08:54 <ajo_> and then (somehow, I don't know how yet) attach those queues to ovs 14:09:13 <ajo_> let me look at the current code & discussion, 1 sec 14:09:25 <ajo_> but may be we can sort that out in the review. Probably we have enough time today. 14:09:54 <ajo_> ah 14:09:56 <ajo_> I see 14:10:06 <ajo_> ralonsoh, hichira is right, that doesn't work, I believe 14:10:08 <hichihara> ralonsoh: I'd like to run the code so please upload a code working 14:10:17 <ajo_> for linux htb to work... 14:10:26 <hichihara> Yeah! 14:10:29 <ajo_> you need to have some hierarchy on the queues over the same device 14:10:30 <ajo_> for example 14:10:46 <ajo_> imagine we did it on the patch port that goes to br-tun 14:10:55 <ajo_> (but that it was a veth, otherwise it does not work). 14:10:57 <ralonsoh> yes 14:11:14 <hichihara> yes, we need use veth 14:11:23 <ralonsoh> ok, I'll review this, but I don't understand your request 14:11:45 <ajo_> you need first, to create the top queue, where you specify the "max" of the link (this is the amount the kernel uses to make sure it substract bandwidth from other ports... beause it's reaching the "top queue" max) 14:11:50 <ajo_> and 14:11:59 <ajo_> under that queue, you add up every separate queue, for every port 14:12:00 <ajo_> so 14:12:02 <ajo_> effectively 14:12:03 <ajo_> you have 14:12:12 <ralonsoh> ok 14:12:16 <ajo_> patch-port-to-br-tun : "queue" max: 10Gbps (for example) 14:12:19 <hichihara> ajo_: ++ 14:12:20 <ajo_> under that queue (hierarchically) 14:12:38 <ralonsoh> but how can I specify the max QoS for tunnel or physical nics? 14:12:40 <ajo_> |_ port 1 queue , min: 1Gbps 14:12:52 <ajo_> |_ port 2 queue, min: 3Gbps 14:12:53 <ajo_> etc... 14:12:55 <ralonsoh> ok 14:13:07 <ajo_> otherwise the linux kernel does not know how to do it 14:13:11 <ajo_> let me send you a link, 1 sec 14:13:30 <hichihara> ajo_: Agree! 14:14:01 <ajo_> ralonsoh, hichihara : https://github.com/mangelajo/ovs-experiments/blob/master/qos/qos_complex_traffic_shapping.sh#L277 14:14:29 <hichihara> nice 14:14:40 <ralonsoh> ajo: perfect, thanks for the info 14:14:44 <ralonsoh> i'll submit a new code 14:14:46 <hichihara> and this link( http://horms.net/projects/openvswitch/2010-10/openvswitch.en.pdf ) helped to understand for me 14:14:50 <ajo_> btw 14:14:59 <ajo_> it seems 14:15:03 <ajo_> (per ovn list conversation) 14:15:10 <ajo_> that we don't necessarily need to create veth ports, 14:15:12 <ajo_> let me explain 14:15:30 <ajo_> for tunnels, we have the physical interface that will handle the traffic (eth0, eth1, ... etc) 14:15:44 <ajo_> so, we create those queues there (apparently, it's possible) 14:15:54 <ajo_> and then that's it 14:16:20 <ajo_> I wonder if we will have to do any magic trick to allow a port which is not directly attached to OVS bridge, to be used to create queues 14:16:29 <ajo_> if that's not possible, we will have to use veths, until that's possible 14:16:45 <ralonsoh> ajo_: ok 14:16:46 <hichihara> But how we know the physical interface? 14:17:10 <ajo_> hichihara, by looking at the tunnel endpoint IP, the default routes, and the system interfaces 14:17:33 <hichihara> I'm OK. We first can try your suggestion. And second plan is veth. 14:17:34 <ralonsoh> ajo_: the tunnel nic is easy 14:17:36 <ajo_> in the case of provider networks, it's easier, because the interface is directly attached to the br-* bridge 14:17:43 <ralonsoh> but not the physical bridge nic 14:17:50 <ajo_> let me look for the ovs mail list message 14:19:42 <ajo_> [ovs-dev] [RFC] QOS using queues in OVN 14:19:43 <ajo_> [ovs-dev] [RFC] QOS using queues in OVN 14:19:44 <ajo_> '':D 14:19:48 <ajo_> my copy paste is crazy 14:20:01 <hichihara> :) 14:20:02 <ajo_> https://www.mail-archive.com/dev@openvswitch.org/msg62077.html 14:20:26 <ajo_> ok, so let's move on the topic 14:20:47 <ajo_> and let's keep working on the technical details, ralonsoh thanks for tackling this blueprint! :) 14:20:59 <hichihara> ajo_: Thanks. I will check your link :) 14:21:15 <ajo_> talking again about 14:21:27 <ajo_> #link https://bugs.launchpad.net/neutron/+bug/1586056 extended rule validation 14:21:27 <openstack> Launchpad bug 1586056 in neutron "[RFE] Improved validation mechanism for QoS rules with port types" [Wishlist,In progress] - Assigned to Slawek Kaplonski (slaweq) 14:22:02 <ajo_> slawek and I created a POC https://review.openstack.org/#/c/319694/ 14:22:15 <ajo_> it's still a very early version 14:22:28 <ajo_> but that would allow us to introduce new fields on the rules 14:22:43 <ajo_> and every mechanism driver / binding type to declare which rules & fields are supported. 14:23:01 <ajo_> for example: 14:23:02 <ajo_> https://review.openstack.org/#/c/319694/8/neutron/plugins/ml2/drivers/openvswitch/mech_driver/mech_openvswitch.py 14:23:09 <ajo_> supported_qos_rule_types = { 14:23:09 <ajo_> qos_consts.RULE_TYPE_BANDWIDTH_LIMIT: { 14:23:09 <ajo_> "max_kbps": [], 14:23:09 <ajo_> "max_burst_kbps": [] 14:23:09 <ajo_> }, 14:23:10 <ajo_> qos_consts.RULE_TYPE_DSCP_MARK: { 14:23:11 <ajo_> "dscp_mark": [] 14:23:15 <ajo_> } 14:23:17 <ajo_> } 14:23:23 <ajo_> if we added direction to bandwidth limit, we could have 14:23:39 <ajo_> "direction": ["egress"], 14:23:44 <ajo_> for sr-iov 14:23:45 <ajo_> and 14:23:52 <ajo_> "direction" : [] 14:23:58 <ajo_> for ovs 14:24:16 <ajo_> and we would add two things 14:24:20 <ajo_> 1) validation at API call levels 14:24:40 <ajo_> to... rule-update, rule-create, port-update (policy), network-update (policy) 14:25:11 <ajo_> so, if we detect an incompatible combination of port + policy-rule(including arguments), we fail the API call with a reasonable explanation for the user/admin. 14:25:23 <ajo_> 2) reporting 14:25:27 <ajo_> by introducing a new call 14:25:50 <ajo_> which would report the binding types (or vnic_type) to rule&argument combinations. 14:25:59 <ajo_> --- 14:26:15 <ajo_> This would enable us to incrementally enhance our rules as necessary 14:26:45 <ajo_> while we support the heterogeneous nature of the technologies we support 14:26:52 <ajo_> (support support... 'X) 14:26:59 <ajo_> --- 14:27:02 <ajo_> the other option would be 14:27:13 <ajo_> we rename the bandwidth-limit rule to egress-bandwidth-limit 14:27:19 <ajo_> and introduce a new ingress-bandwidth-limit 14:27:37 <ajo_> and, same thing goes to all other directional rules (like the min bw ralonsoh is working on) 14:27:40 <ajo_> ------ 14:27:52 <ajo_> but we would hit the same problem the day we introduce support for traffic classifiers... 14:28:12 <ajo_> if we attach a classifier to rules, ... some technologies will support that, some will not 14:28:21 <ajo_> ---- 14:28:29 <ajo_> ralonsoh, njohnston , hichihara , ihrachys thoughts? 14:29:00 <ralonsoh> I need to review the code and ground any idea... 14:29:18 <njohnston> ^^ what he said :-) 14:29:22 <ajo_> lol ':D 14:29:33 <ajo_> heavy duty stuff, sorry guys :D 14:29:39 <ralonsoh> But I think the first option (with directions) is better 14:29:46 <ajo_> if you have time to review the RFE and the ideas... 14:29:52 <ralonsoh> I mean: have a parameter with the direction 14:30:02 <ajo_> yes, that's the basis, if we believe that extending rules that way is more healthy... then that's the way 14:30:04 <ajo_> I believe that 14:30:23 <ajo_> all the above stuff boils down to... 14:30:41 <ajo_> imagine that you have a network with 4 ports, 2 OVS ports, and 2 SR-IOV ports 14:30:56 <ajo_> and that network has a policy "A", with a bw limit rule on egress, 10Mbps 14:31:04 <ajo_> admin comes via api and tries 14:31:18 <ajo_> neutron qos-policy-rule-update "A" <rule-id> --direction ingress 14:31:25 <ajo_> it should fail with a meaningful message 14:31:46 <ajo_> "port X binded by sr-iov, does not support direction: ingress for this rule.." 14:32:06 <ajo_> I should have started by that ':D 14:32:18 <ralonsoh> hehehe agree! 14:32:37 <hichihara> I agree the arrangement. QoS is complexed for me. We need to make it more uniform. 14:33:22 <ajo_> thanks hichihara , yes, it's indeed a complex topic, because not all technologies can implement the same features. 14:33:46 <ajo_> and if we stick to the minimum subset, we just ended with DSCP & max bw egress... :) 14:34:17 <ajo_> ok, let's move on 14:34:23 <ajo_> #topic non approved RFE's 14:34:25 <ajo_> https://bugs.launchpad.net/neutron/+bugs?field.tag=qos+rfe+&field.tags_combinator=ALL 14:34:30 <ajo_> let's see if we have something new around 14:35:08 <ajo_> it looks like not 14:35:15 <ajo_> ok, 14:35:50 <njohnston> Can the traffic classification RFE be moved out of incomplete status? 14:35:51 <ajo_> let me link this tangential RFE: https://bugs.launchpad.net/neutron/+bug/1563967 14:35:51 <openstack> Launchpad bug 1563967 in neutron "[RFE] Extend l2-extensions-api for flow management " [Wishlist,Triaged] - Assigned to Miguel Angel Ajo (mangelajo) 14:36:02 <ajo_> njohnston, let me see, sec 14:38:37 <ajo_> so they moved it to incomplete because we were prioritizing other things: https://bugs.launchpad.net/neutron/+bug/1563967 14:38:37 <openstack> Launchpad bug 1563967 in neutron "[RFE] Extend l2-extensions-api for flow management " [Wishlist,Triaged] - Assigned to Miguel Angel Ajo (mangelajo) 14:38:37 <ajo_> sorry 14:38:42 <ajo_> http://eavesdrop.openstack.org/meetings/neutron_drivers/2016/neutron_drivers.2016-03-24-22.01.log.html#l-104 14:39:08 <ajo_> the RFE is bound to having classifiers, and I guess we need to solve that first 14:39:20 <ajo_> davidsha, how do you see it ? 14:40:17 <davidsha> ajo_: I agree, priority queuing requires traffic to be classified and funneled into 4 queues, so the Common classifier is a requirment 14:40:57 <njohnston> Ok got it 14:41:07 <ajo_> davidsha, may be we could move it back to Wishlist, but I wonder how do we do if it's dependent into classifiers 14:41:20 <ajo_> I wouldn't make sense to get it approved without the dependency first 14:41:31 <ajo_> davidsha, any advance on the classifier front ? I've lost track of that thread 14:43:01 <davidsha> ajo_: the rfe was filed, thats all thats been done so far 14:43:54 <ajo_> davidsha, ok, let's keep tracking it 14:44:06 <davidsha> ajo_: there is an old spec for neutron_classifier that we may refurbish for this. 14:44:13 <ajo_> :) 14:44:50 <ajo_> davidsha, about the L2 flow extensibility: https://bugs.launchpad.net/neutron/+bug/1563967 any thoughts which could be important? reviews on the spec are welcomed from anywone: 14:44:50 <openstack> Launchpad bug 1563967 in neutron "[RFE] Extend l2-extensions-api for flow management " [Wishlist,Triaged] - Assigned to Miguel Angel Ajo (mangelajo) 14:45:08 <davidsha> ajo_: I have the PoC done, I'll put it up now. 14:45:11 <ajo_> https://review.openstack.org/#/c/320439/ 14:45:18 <ajo_> but I know it's a heavy duty topic too 14:45:22 <ajo_> davidsha++ 14:45:41 <ajo_> I think our highest priority things now shall be the extended validation and this, 14:46:03 <ajo_> first is a blocker for other rfes to merge 14:46:24 <ajo_> and this one, not 100% a blocker, but it will be important for QoS to interoperate with other extensions 14:46:26 <ajo_> gracefully 14:47:16 <ajo_> probably we should move to bugs 14:47:23 <davidsha> kk, there aren't any tests worth mentioning yet, but I've set up dscp to use it and make sure it can work 14:47:39 <ajo_> niiice 14:47:53 <ajo_> looking forward to see it 14:48:11 <ajo_> #topic bugs 14:48:14 <ajo_> https://bugs.launchpad.net/openstack/+bugs?field.searchtext=&orderby=-importance&field.status:list=NEW&field.status:list=OPINION&field.status:list=EXPIRED&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=FIXCOMMITTED&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&fie 14:48:14 <ajo_> ld.subscriber=&field.structural_subscriber=&field.tag=qos+-rfe&field.tags_combinator=ALL&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search 14:48:18 <ajo_> woops sorry 14:48:25 <njohnston> Whoa 14:48:28 <ajo_> #link http://bit.ly/1WhXlzm 14:48:40 <ajo_> thank god njohnston had a shorter version of it :) 14:48:58 <ajo_> I'm working on : https://bugs.launchpad.net/networking-ovn/+bug/1584204 14:48:58 <openstack> Launchpad bug 1584204 in neutron "VersionsCallbackNotFound exception when using QoS" [Undecided,In progress] - Assigned to John Kasperski (jckasper) 14:49:10 <ajo_> it shall be almost there 14:49:31 <ajo_> njohnston, how's it going with: https://bugs.launchpad.net/neutron/+bug/1486607 14:49:31 <openstack> Launchpad bug 1486607 in neutron "tenants seem like they were able to detach admin enforced QoS policies from ports or networks" [Medium,In progress] - Assigned to Nate Johnston (nate-johnston) 14:49:45 <ajo_> probably you're waiting for review.... :'( 14:49:56 <njohnston> I think it just needs +2s 14:50:28 <ajo_> https://review.openstack.org/#/c/217092/ 14:50:30 <ajo_> the patch, 14:50:43 <ajo_> yes I remember the complications because of the no exchangeability of policy.json to check it 14:50:51 <ajo_> I will prioritize that again, sorry for the delay 14:50:57 <njohnston> Thanks! 14:51:27 <ajo_> thank you! :D 14:52:19 <ajo_> the pecan bug https://bugs.launchpad.net/neutron/+bug/1568400 could be fixed by: https://review.openstack.org/#/c/314886/ 14:52:19 <openstack> Launchpad bug 1568400 in neutron "Pecan does not route to QoS extension" [Medium,In progress] - Assigned to Brandon Logan (brandon-logan) 14:52:22 <ajo_> we probably need to check 14:53:51 <ajo_> the patch for https://bugs.launchpad.net/neutron/+bug/1515564 needs to be rebuilt on top of the great refactor by mfranc213 :D 14:53:51 <openstack> Launchpad bug 1515564 in neutron "Internal server error when running qos-bandwidth-limit-rule-update as a tenant" [Low,In progress] - Assigned to Liyingjun (liyingjun) 14:54:16 <ajo_> mfranc213, did a good job with the qos_plugin.py refactor 14:54:40 <ajo_> ahh 14:54:42 <ajo_> there's a new version 14:54:48 <ajo_> in fact it seems like it's already been rebased 14:55:04 <ajo_> so, adding to my queue too 14:56:31 <hichihara> ajo_: Before end meeting, can I ask you about Strict minimum bandwidth? 14:56:41 <ajo_> https://bugs.launchpad.net/networking-qos/+bug/1585373 14:56:41 <openstack> Launchpad bug 1585373 in networking-qos "qos-policy update without specify --shared causing it change to default False" [Undecided,Confirmed] - Assigned to ugvddm (271025598-9) 14:56:48 <ajo_> this was on the wrong project ^fixing 14:57:00 <ajo_> hichihara, ah, that one depends on the generic resource pool implementation at the nova side 14:57:08 <ajo_> I suspect we could implement it on next cycle 14:57:16 <hichihara> However, Do we keep to pray these good progress only? 14:57:21 <ajo_> based on the mailing list discussions (linked form the RFE) 14:57:23 <hichihara> Don't we need to propose nova spec about new resource(NIC_BW?) for generic resource pool like SRIOV? 14:58:07 <ajo_> hichihara, not sure if those will need to be declared in code, or via API, hichihara do you have time to check that with Jaypipes ? 14:58:23 <ajo_> it's good to keep an eye on that, 14:58:28 <hichihara> ajo_: OK. 14:58:37 <ajo_> also, about non-strict, we may need to look at SR-IOV 14:59:01 <ajo_> I think it's rather easy to do, but we may need to ask the intel or melanox guys about the link settings for min bw, etc 14:59:05 <ajo_> ralonsoh, ^ 14:59:08 <hichihara> ajo_: I will consider what we need. 14:59:11 <ajo_> and may be loop somebody else to help with that 14:59:13 <ralonsoh> I know 14:59:16 <ajo_> thanks :) 14:59:24 <ajo_> I suspect we should endmeeting 14:59:30 <ralonsoh> bye! 14:59:35 <ajo_> so, again thanks a lot everybody 14:59:35 <davidsha> Thanks! 14:59:38 <hichihara> bye! 14:59:43 <ajo_> o/ :) 14:59:51 <ajo_> #endmeeting