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