22:00:14 <kevinbenton> #startmeeting neutron_drivers 22:00:15 <openstack> Meeting started Thu Apr 13 22:00:14 2017 UTC and is due to finish in 60 minutes. The chair is kevinbenton. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:00:18 <openstack> The meeting name has been set to 'neutron_drivers' 22:00:22 <mlavalle> o/ 22:00:34 <kevinbenton> This may be a short meeting, we are short both Ihar and Armando 22:00:42 <mlavalle> LOL 22:00:46 <kevinbenton> and I don't see Akihiro online yet either :) 22:01:01 <mlavalle> let's wait a couple of minutes 22:01:19 <kevinbenton> well I know Ihar and Armando can't make it, they both reached out ot me 22:01:28 <mlavalle> ahhh 22:01:41 <mlavalle> do you want to postpone to next week? 22:02:11 <kevinbenton> i would like to point out an RFE that mordred posted 22:02:27 <mlavalle> cool 22:02:37 <bzhao> o/ 22:02:38 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1682247 22:02:39 <openstack> Launchpad bug 1682247 in neutron "Neutron should be able to fetch hostkeys for ports" [Wishlist,Triaged] 22:02:46 <kevinbenton> This feature request is a little unique 22:02:51 <mlavalle> oh yeah, I just read it 22:03:02 <kevinbenton> because it involves having a neutron API that will go into the tenant network dataplane 22:03:06 <mlavalle> I mean the RFE and the spec 22:03:21 <mlavalle> right 22:03:22 <kevinbenton> to ask the instance for info 22:03:32 <kevinbenton> we don't really have anything like that right now 22:03:39 <mlavalle> yeap 22:03:56 <mlavalle> the dataplane belongs to the tenant 22:04:06 <mlavalle> once we wire it 22:04:41 <kevinbenton> thinking about how this would be implemented, we basically need one of the agents to execute code in a namespace on the tenant network 22:04:50 <kevinbenton> (in the reference implementation) 22:04:55 <mlavalle> right 22:05:22 <mlavalle> the dhcp agent, maybe? 22:05:35 <kevinbenton> yeah, we could probably piggyback on the DHCP agent 22:05:51 <kevinbenton> the question is where do we send it from if dhcp is disabled on the subnet 22:05:55 <mlavalle> that's the one is going to be there all the time 22:06:07 <mlavalle> ahh right? 22:06:10 <mlavalle> right 22:06:40 <kevinbenton> I'll leave some questions on the RFE and we can discuss it more when we have a full house next week 22:06:52 <kevinbenton> mordred: are you around? 22:07:48 <kevinbenton> mlavalle: ok, anything you want to chat about while we are here? :) 22:07:55 <mlavalle> yeah 22:08:43 <mlavalle> in preparation for the meeting, to refresh my memory, I went thorugh all the RFE's 22:08:53 <mlavalle> looking at https://bugs.launchpad.net/neutron/+bug/1639566 22:08:55 <openstack> Launchpad bug 1639566 in neutron "[RFE] Add support for local SNAT" [Wishlist,Triaged] 22:09:13 <mlavalle> I think we can scrap this one, based ont he submitter latest comment 22:09:32 <mlavalle> he took a look at swami's fast exit approach 22:09:37 <mlavalle> and he seems to like it 22:09:52 <mlavalle> I left a question there, to confirm he is ok if we scrap it 22:10:12 <kevinbenton> yeah, i saw that, but I was a little confused 22:10:30 <mlavalle> let's see if he responds to my question 22:10:31 <kevinbenton> because fast exit doesn't solve the same use case I was thinking of (but I need to read swami's patch) 22:10:48 <kevinbenton> i didn't think fast exit applied to SNAT 22:11:02 <mlavalle> I haven't had time to understand fast exit 22:11:16 <mlavalle> I am just reacting to what the submitter commented in the RFE 22:11:36 <mlavalle> But maybe we should understand the fast exit stuff better, at least me 22:11:39 <kevinbenton> yeah 22:11:45 <kevinbenton> i think we'll just leave it sit there 22:11:53 <kevinbenton> and wait for response 22:11:57 <mlavalle> yeah 22:12:28 <mlavalle> going back to modred's rfe, we could create the dhcp namespace even if the subnet has dhcp disabled 22:12:40 <kevinbenton> mlavalle: yes 22:12:40 <mlavalle> we don't start dnsmasq 22:12:50 <kevinbenton> mlavalle: but we would then need to consume an IP from the subnet 22:13:10 <mlavalle> yeap, just brainstorming 22:13:21 <kevinbenton> mlavalle: that may be reasonable trade-off 22:13:43 <mlavalle> ok, I'll leave a comment in the rfe and we can discuss further next week 22:14:06 <kevinbenton> sounds good 22:14:13 <trevormc> I'm here if you had more questions on bug 1662650 :) 22:14:14 <openstack> bug 1662650 in neutron "[RFE] Advance configuration of SR-IOV ports- api extension" [Wishlist,Triaged] https://launchpad.net/bugs/1662650 - Assigned to Trevor McCasland (twm2016) 22:15:17 <kevinbenton> trevormc: i haven't had a chance to look at your patch yet. i'll add that to my list 22:15:26 <trevormc> there is new functionality in dpdk that we would like to use, to include this new api http://dpdk.org/doc/api/rte__pmd__i40e_8h.html 22:16:05 <trevormc> ok thanks, the patches aren't much as the tests don't pass but were to just give an idea. 22:16:19 <mlavalle> trevormc: I read you lastest comments before the meeting 22:16:42 <kevinbenton> trevormc: it would be better if you could break these out into separate RFEs 22:17:06 <kevinbenton> trevormc: many of these are completely unrelated from a user-facing feature perspective 22:17:09 <reedip_> o/ 22:17:10 <trevormc> yeah that sounds reasonable. 22:17:29 <mlavalle> does this mean that after matching with currently available functionality, you only need to add boradcat, unicast and multicast to security groups? 22:18:10 <kevinbenton> +1. if that's the only thing left, then just update the existing RFE description for the use case of altering hte security groups API 22:18:12 <trevormc> mlavelle: I haven't been able to confirm if it works with dpdk and sr-iov. There is some issue between kernel and userspace 22:18:45 <mlavalle> trevormc: so it would be very helpful if we can confirm that 22:18:57 <mlavalle> it allows us to size the beast 22:18:57 <kevinbenton> trevormc: be sure to focus on what this is enabling for users via the API 22:19:24 <kevinbenton> trevormc: we can't move forward with just the intention of exposing a bunch of flags available in DPDK if there isn't a clear use case for users 22:19:34 <mlavalle> ++ 22:20:27 <trevormc> yeah ok, I will think of a clear way of showing the new API. The flags are supposed to enable the functionality in the NIC for low-latency networking is my understanding. 22:20:53 <mlavalle> thanks trevormc! 22:21:29 <kevinbenton> ok 22:21:32 <kevinbenton> anything else? 22:21:39 <mlavalle> not from me 22:21:41 <trevormc> no thats all thanks for breaking that down for me. 22:21:51 <kevinbenton> cool 22:21:57 <kevinbenton> see everyone next week then! 22:22:03 <mlavalle> o/ 22:22:05 <kevinbenton> #endmeeting