13:01:49 <baoli> #startmeeting PCI passthrough
13:01:49 <openstack> Meeting started Tue Dec 16 13:01:49 2014 UTC and is due to finish in 60 minutes.  The chair is baoli. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:50 <sadasu> Hello
13:01:53 <openstack> The meeting name has been set to 'pci_passthrough'
13:01:53 <baoli> Hi
13:02:03 <jchapman> Hey
13:02:05 <beagles> o/
13:02:15 <moshele> hi
13:02:28 <baoli> Shall we focus on the bps/specs today?
13:02:41 <sadasu> ok
13:02:47 <yongilhe> yeah
13:02:51 <shaohe_feng> hi
13:03:05 <baoli> shaohe_feng: looking at your spec now
13:03:34 <shaohe_feng> baoli: thank you.
13:03:53 <baoli> shaohe_feng: your use case description is pretty interesting.
13:04:24 <shaohe_feng> baoli: jaypipes help me to improve it. :)
13:04:42 <irenab> I would like to introduce moshele, who is going to work on SRIOV related issues as well
13:05:04 <moshele> hi, everyone
13:05:05 <baoli> moshele: Hi, welcome. full name?
13:05:13 <moshele> Moshe Levi
13:05:24 <yongilhe> hi, moshele
13:05:42 <shaohe_feng> moshele: hi.  welcome. I'm also a fresher. :)
13:06:08 <moshele> shaohe_feng: :)
13:06:26 <itzikb> moshele: welcome :-)
13:06:37 <sadasu> welcome moshele
13:06:45 <baoli> Looks like that we need +2s for our specs.
13:07:31 <jchapman> Hi baoli: can you have a look at https://blueprints.launchpad.net/nova/+spec/sriov-sched-with-stateless-offloads
13:07:34 <yongilhe> baoli, this is..., how we get foucs,
13:08:15 <baoli> jchapman, ok, looking
13:08:55 <irenab> There is one more topic we must address: neutron split that happens during Kilo
13:09:01 <baoli> jchapman, I saw you added more stuff in the testing section.
13:09:25 <jchapman_> baoli: He just a little detail on testing, Sean wanted it
13:09:49 <jchapman_> I also opened a RFE on libvirt
13:10:37 <baoli> jchapman_: looks good to me. will +1. What's the RFE on libvirt about?
13:12:45 <baoli> jchapman_: what's the libvirt RFE?
13:12:46 <jchapman> baoli: sorry i got kicked out. The RFE is from a comment from sahid
13:13:17 <jchapman> baoli: Its not a bug its more a feature request, but we are working on the patch fro this now
13:14:31 <baoli> jchapman: I see.
13:15:25 <baoli> jchapman_: one more question. Given that the sriov properties are specified with the image, so .0 means the first sriov port as specified in the order of --nic arguments?
13:15:47 <jchapman> baoli: exactly
13:17:07 <baoli> jchapman, thinking about the way it's specified, would it open a door to declare a sriov port in the image, something like: port.0=sriov, caps, etc?
13:17:39 <baoli> irenab, can we discuss that in a bit?
13:17:51 <irenab> baoli: ok
13:17:58 <jchapman> baoli, irendb, sure, lets chat later
13:19:08 <yongilhe> irenab, boli, and all, how could get focus, bp deadline is soon..
13:19:30 <irenab> For neutron the deadline was yesterday
13:20:26 <yongilhe> irenab, en, i know, do you have bp approved?
13:20:34 <irenab> I am not sure what is the status of https://review.openstack.org/#/c/138753/, it did not get either +2 nor -2 yet
13:21:12 <irenab> the SR-IOV traffic rate was rejected to L release
13:21:31 <baoli> jchapman: sorry, I was referring to Irenab's earlier request for neutron split discussion after asking you that question about sriov port.
13:21:53 <jchapman> baoli: ok no prob
13:22:15 <irenab> so about the split...
13:22:58 <irenab> neutron drivers team approved the split between neutron as integration platform and neutron backends
13:23:03 <baoli> irenab: seems like that there will be exceptions. So we may want to reach for the cores.
13:23:08 <irenab> including ML2 mechanism drivers
13:23:47 <yongilhe> small repos means more core to review the feature, this might be good thing.
13:23:48 <irenab> which means that neutron MD/plugin code should be hosted out of the neutron tree (stackforge)
13:24:35 <sadasu> irenab: the ML has some activity on how diff drivers are trying to do their split
13:24:53 <irenab> We still need to see if Ml2 as sub-community wants to host all MDs together, but according to started efforts for ODL and Arista drivers seems that everyone goes by itself
13:25:34 <irenab> I think that here we can decide what makes sense for us and suggest it
13:25:35 <sadasu> for ML2 drivers I think there is some discussion on what remains in tree and what goes out
13:26:10 <sadasu> irenab: as I understand, yes, every driver is going with a seperate repo
13:27:01 <irenab> So seems that we should take the SRIOV MD out and maintain it at stackforge
13:27:21 <baoli> irenab: the common one?
13:28:01 <irenab> baoli: I think we should decide what is the most reasonable way to do it
13:28:02 <sadasu> baoli: no choice in that matter..yes common one goes out too
13:28:38 <sadasu> irenab: are you suggesting that the common sr-iov mech driver should stay in tree?
13:28:50 <irenab> for example there is a proposal for OVS-DPDK MD, it is also not vendor specific but technology specific
13:29:31 <baoli> irenab, does that remain in tree?
13:29:36 <irenab> but making it repository at stackforge has its implications, i.e. who is responsible to vote +2 and apporve code that lands there
13:29:46 <irenab> baoli: not
13:30:02 <baoli> irenab, that is what I'm thinking.
13:30:33 <irenab> the split process is described here: https://review.openstack.org/#/c/141171/
13:30:34 <sadasu> irenab: I know it will not be the neutron cores :-)
13:31:21 <irenab> sadasu: its up to maintainer to set this
13:31:41 <sadasu> irenab: I have read this spec several times
13:32:10 <sadasu> it appears that each (stackforge) repo can decide who it wants to give +2 rights to
13:32:33 <sadasu> ireanb: yes...agreed
13:33:23 <irenab> So with regards to SR-IOV MD, I guess this team is actually the right people to become maintainers for this MD, but maybe we need to consider wider scope
13:34:09 <baoli> irenab, by wider scope, you mean?
13:34:44 <irenab> baoli: generic MDs (not vendor specific) repo
13:35:12 <irenab> I would suggest to discuss it also tomorrow at ML2 meeting and then decide which way to make the split
13:35:51 <sadasu> we should discuss this at the ml2 meeting
13:36:28 <sadasu> it might be possible to still be able to inherit from this generic MD even if it is in a seperate repo
13:36:33 <irenab> There are already examples on how to make the split started by some vendor, so technically it should not be too complicated
13:37:28 <baoli> irenab, so what's your proposal?
13:37:49 <irenab> sadasu: Maybe it makes sense to keep some MDs together and try to reuse code or maybe refactor the code to have some basic code in tree
13:38:45 <irenab> baoli: Actually, I am a bit confused right now. One thing for sure, we cannot keep the code in tree
13:38:59 <sadasu> keeping it in tree might be hard to convince...you can try
13:39:12 <sadasu> we can still get organized out of tree
13:39:33 <baoli> irenab, ok. I'm kind of struggling as well. The MD is not a big chunk of code. And it needs to be maintained separately.
13:39:33 <irenab> so we can start the split, give all relevant people voting rights and see what should be done next
13:40:52 <baoli> does that mean: generic MD goes to a repo, and vendor MDs goes to separate repos.
13:40:57 <irenab> baoli: agree, just for exmple if sadsu wanted to reuse it, it maybe more complicated now
13:41:30 <irenab> baoli: this is waht I would like to discuss with ML2 team
13:41:55 <baoli> irenab, so let's bring it up in that meeting.
13:42:16 <irenab> so lets see waht will be ML2 subteam suggestion and then decide what to do
13:42:53 <baoli> how is this going to be hooked up with devstack? If I want to use a MD, the devstack has to download from various repos.
13:43:22 <irenab> baoli: yes. I think moshele already checked how this can be done
13:43:42 <baoli> irenab, that sounds good.
13:43:46 <sadasu> baoli: yes corresponding devstack changes have to be made too
13:44:24 <irenab> Shall we move to the next topics?
13:44:46 <baoli> but the thing is that devstack becomes vendor specific, right?
13:45:20 <irenab> baoli: I do not think so, you canjust point what repos to download
13:45:52 <baoli> irenab, how about vendor specific config?
13:46:15 <sadasu> currently that stays in tree
13:46:22 <sadasu> and the verndor specific db changes
13:46:34 <irenab> baoli: and extensions also
13:47:06 <baoli> irenab, sadasu: ok
13:47:07 <irenab> baoli: it is going to be a challange ...
13:48:44 <baoli> alright, any other topics? otherwise, can we go back to the question that I asked earlier on the image associated sriov properties?
13:49:52 <irenab> no other topic for me
13:50:15 <yongilhe> neutron going to be scatter, will this mean sriov featrue we are doing is high possible to delay?
13:51:14 <irenab> yonglihe: can you please clarify your question?
13:51:48 <yongilhe> irenab, i.e, your bp,  been impact most likely
13:51:56 <yongilhe> until split is done?
13:52:51 <irenab> seems that neutron priories for Kilo mostly around refactor and split everything
13:53:39 <yongilhe> irenab, yeah i concern this, this mean we might can not get focus, casue big change happenning
13:54:19 <sadasu> yongilhe: this is neutron specific, so Nova should be unaffected
13:54:37 <irenab> yonglihe: yes, but maybe further we can move much faster if no infra change will be required
13:55:03 <yongilhe> irenab, i also think this is a good thing somehow,
13:55:13 <yongilhe> i hope nova get split also
13:55:42 <yongilhe> it's much bigger than neutron, schduler is on going.
13:56:22 <irenab> yonglihe: for nova seems the direction is exactly the opposite. For vif_drivers was strong objection to allow out of tree support
13:57:39 <yongilhe> baoli, irenab, i also had a rough idea, the sriov tag, physical network might don't needed, if neutron had interface mapping, can use to inject property to pci devices.
13:57:45 <irenab> younglihe: you should be aware of split for CI to keep running
13:58:09 <yongilhe> irenab, thanks remind this.
13:58:27 <baoli> yongilhe, can you be specific on interface mapping?
13:59:18 <yongilhe> baoli, we had configration for vlan:  mapping: phynet1:eth1 something like this
13:59:46 <yongilhe> then, we can inject or query neutro to get the pci device informations to nova,
13:59:48 <irenab> yonglihe: this is for neutron agent
14:00:12 <irenab> yonglihe: lets discuss it next meeting
14:00:22 <yongilhe> irenab, yeah, anyway, we had redundent information about this
14:00:38 <irenab> yonglihe: agree
14:00:58 <yongilhe> this might could be elimated somehow, let's going on next time.
14:01:09 <baoli> yongilhe: we had discussion on this earlier, I remember. So let's keep looking at it.
14:01:20 <baoli> thanks everyone
14:01:25 <yongilhe> thanks,
14:01:27 <irenab> thanks
14:01:41 <moshele> thanks
14:01:42 <sadasu> thanks
14:01:46 <baoli> #endmeeting