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