16:04:26 <rkukura> #startmeeting networking_ml2
16:04:26 <openstack> Meeting started Wed May 31 16:04:26 2017 UTC and is due to finish in 60 minutes.  The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:04:29 <openstack> The meeting name has been set to 'networking_ml2'
16:04:54 <rkukura> meetbot seems to work :)
16:05:08 <rkukura> Sukhdev said he can’t make the meeting today
16:05:13 <rkukura> #topic Agenda
16:05:26 <rkukura> #link https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_May_31.2C_2017
16:05:50 <rkukura> not much structure to the recent agendas
16:05:57 <rkukura> anyone want to add anything specific?
16:05:58 <sadasu> I have a couple of questions for trevormc
16:06:09 <trevormc> ok shoot :)
16:06:20 <rkukura> should we get to those under RFEs, or is this unrelated?
16:07:16 <sadasu> one is about the q-in-q type driver code review
16:07:31 <rkukura> sadasu: Should we cover these when we get to RFEs?
16:07:41 <sadasu> and the other is about the SR-IOV  tap rfe
16:07:54 <sadasu> sure.
16:07:56 <rkukura> OK
16:08:03 <rkukura> #topic Annoucements
16:08:13 <rkukura> No announcements from me - anyone else?
16:08:34 <rkukura> #topic RFEs/Bugs
16:08:41 <rkukura> sadasu: go ahead…
16:08:56 <trevormc> umm the bug https://bugs.launchpad.net/neutron/+bug/1693240 was decided to be a normal bug and not an RFE so I can start working on it now :0
16:08:57 <openstack> Launchpad bug 1693240 in neutron "Support SRIOV VF VLAN Filtering" [Wishlist,Confirmed] - Assigned to Trevor McCasland (twm2016)
16:09:58 <sadasu> ok..haven't looked at that yet
16:11:03 <trevormc> no need to look into it, I just wanted to say it is no longer being held back in the RFE review process
16:11:09 <sadasu> cool
16:11:27 <sadasu> trevormc: regarding the q-in-q type driver
16:11:49 <sadasu> do you have some reservations about your get_mtu() method?
16:12:19 <sadasu> when I looked at your patchiest first, I did spend quite some time on this method and talked to folks about it
16:12:43 <sadasu> conclusion: that method is fine. do you have something specific you are worried about?
16:12:49 <sadasu> patchiest*
16:13:10 <sadasu> spell check working its magic with patch set
16:13:18 <trevormc> sadasu: thanks for confirming the method being fine. I was just worried the mtu size would have to be smaller than VLAN because of the extra header
16:13:32 <trevormc> but if thats not the case then, no worries.
16:14:34 <sadasu> ok..let me double check your concern and post my final comment on the review itself
16:15:07 <trevormc> that would be great, thank you!
16:15:38 <sadasu> should I proceed to question#2?
16:15:46 <trevormc> yes
16:15:47 <rkukura> sadasu please
16:16:28 <sadasu> this is regarding the SR-IOV being supported under tap-aaS
16:17:06 <sadasu> there are 2 SR-IOV modes supported in nova/neutron "direct" and "macvtap"
16:17:22 <sadasu> tap-aaS can be supported only in the macvtap mode
16:17:46 <sadasu> macvtap is implemented in the kernel as mtacvlan, afaik
16:17:54 <sadasu> are you working in that direction?
16:18:33 <trevormc> sadasu: this is good info. I cannot say what the implementation details are.
16:18:35 <sadasu> "macvlan"*
16:18:58 <trevormc> ... I know this is not the answer you want to hear, but I was hoping to talk with the research team more about this.
16:19:16 <sadasu> yes, I remember you saying that in the last meeting
16:19:43 <sadasu> thats why I am getting you some information that might help you with defining the direction a little better
16:20:15 <trevormc> thanks, I spent most of the time talking about the vlan filtering. I think we want to do it with direct ports.
16:20:45 <trevormc> I'll get an answer for you wrt direct or macvtap ports
16:21:39 <sadasu> I think the important distinction between "direct" and "macvtap" is that the kernel looses control of the "direct" port as soon as it is assigned to the VM
16:22:14 <trevormc> right, VFd is supposed to be an implementation of the kernel driver to give the information back
16:22:32 <trevormc> s/information/control
16:23:01 <trevormc> https://github.com/att/vfd/tree/master/src/vfd
16:23:16 <trevormc> currently it says, "Future support for mirroring is planned."
16:23:24 <trevormc> so I will have to ask what the details are on this.
16:23:35 <sadasu> ah! thanks for the link. Didn't know about it
16:24:32 <trevormc> yeah a lot of people don't know about vfd but it is apart of dpdk now so we can integrate it easily... i think :)
16:24:36 <sadasu> ok. nothing more from me until I take a look at the additional info you just provided me
16:24:46 <trevormc> see http://dpdk.readthedocs.io/en/latest/nics/intel_vf.html#dpdk-sr-iov-pmd-pf-vf-driver-usage-model
16:25:44 <trevormc> just the whole page, not just the div i linked.
16:25:58 <rkukura> trevormc: Anything more you’d like to report related to your SR-IOV work?
16:26:16 <sadasu> trevormc: thanks again
16:26:28 <trevormc> rkukura: its currently blocked because I need a lab that has the required hardware.
16:26:39 <trevormc> I'm working on getting one
16:27:02 <rkukura> trevormc: OK, thanks
16:27:08 <trevormc> sadasu: thank you for looking into the capabilities, its really useful, especially for computing noob like myself.
16:27:56 <rkukura> Any other questions related to the SR-IOV RFEs/bug/work?
16:28:04 <sadasu> trevormc: you are welcome! I am no expert either.
16:28:13 <trevormc> not from me.
16:28:20 <rkukura> thank you both!
16:28:51 <rkukura> minor update on the RFE I had submitted on extension semantics enforcement…
16:29:11 <rkukura> #link https://bugs.launchpad.net/neutron/+bug/1673142
16:29:12 <openstack> Launchpad bug 1673142 in neutron "[RFE][ML2] Enforce extension semantics" [Wishlist,Triaged]
16:29:37 <rkukura> seems the driver’s team is happy with the RFE, but wants a spec
16:29:57 <rkukura> I hope to find out in the next week whether I will have any time to work on this near term
16:30:25 <rkukura> that’s it from me on this
16:30:49 <sadasu> rkukura: will read the detailed RFE
16:30:58 <rkukura> sadasu: thanks
16:31:06 <rkukura> Any other RFEs/Bugs to discuss today?
16:31:35 <trevormc> no
16:31:50 <rkukura> if not…
16:31:55 <rkukura> #topic Open Discussion
16:32:20 <rkukura> Anything to discuss today?
16:32:27 <rkukura> Or readty to wrap up?
16:32:38 <rkukura> s/readty/ready/
16:32:40 <sadasu> I don't have anything
16:32:41 <trevormc> im ready :)
16:33:01 <rkukura> OK, thanks for joining today! See you next week!
16:33:08 <sadasu> thanks all!
16:33:12 <rkukura> #endmeeting