13:00:54 <baoli> #startmeeting PCI Passthrough
13:00:55 <openstack> Meeting started Tue Dec 23 13:00:54 2014 UTC and is due to finish in 60 minutes.  The chair is baoli. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:58 <openstack> The meeting name has been set to 'pci_passthrough'
13:01:07 <baoli> Hello
13:01:11 <yongilhe> hello
13:01:11 <irenab> Hi
13:01:12 <pczesno> Hi
13:01:12 <beagles> hi
13:01:37 <yongilhe> i guess next meeting should cancel
13:01:44 <ijw> ello
13:02:17 <yongilhe> hi, ijw
13:02:46 <baoli> I will be off until after new year.
13:03:04 <baoli> Should we have the next meeting on Jan. 6th, then
13:03:07 <yongilhe> baoli, sure, happy new year.
13:03:32 <baoli> yonilhe, you too, and merry christmas and happy holidays to everyone
13:04:19 <pczesno> thanks, happy holidays to everyone
13:04:44 <irenab> happy holidays
13:04:48 <baoli> Agenda: https://wiki.openstack.org/wiki/Meetings/Passthrough
13:04:54 <baoli> #topic, bugs
13:05:34 <baoli> any update?
13:06:25 <baoli> no new bugs
13:06:29 <baoli> #topic, reviews
13:06:53 <irenab> baoli: I updated status of neutron specs
13:07:11 <baoli> irenab, you mean the blueprints?
13:07:25 <baoli> on the agenda?
13:07:27 <irenab> baoli: yes
13:08:11 <irenab> baoli: sorry, it is next topic
13:08:29 <baoli> irenab, no problem.
13:09:18 <baoli> One issue with PCI passthrough that has been there for a long time is the pci init.
13:09:29 <baoli> We opened a few bugs
13:09:55 <baoli> but we need to come to consensus on the solution. and drive it to completion
13:10:19 <yongilhe> to resolve the critical bug, i had to collection the status from db
13:10:44 <irenab> baoli: all new bugs are tagged for pci, do you want to provide a link?
13:11:09 <yongilhe> and the new patch is released, in this way, we don't need reading back the db at the pci manager init.
13:12:07 <yongilhe> #link https://review.openstack.org/#/c/131321/
13:12:59 <baoli> https://review.openstack.org/#/c/82206/
13:12:59 <baoli> https://review.openstack.org/#/c/102298/
13:13:01 <baoli> a couple of reviews on the issue:
13:13:29 <baoli> The first one is abandoned, but provides some context/comments on the issue
13:14:09 <baoli> yongilhe, I think that the reconciliation should be performed explicitly during init time.
13:14:38 <yongilhe> baoli, why
13:16:20 <baoli> yongilhe, the purpose is to make sure that the contents in the DB table and the PCI devices on a node are the same.
13:17:36 <yongilhe> boali, it's ture, but don't neccessary to sync it at init, this way is also works:https://review.openstack.org/#/c/131321/
13:18:06 <yongilhe> in this way, we colleciton the pci device back from instance, just like vcpu/memory resource
13:18:45 <yongilhe> then help to reduce the resize resource management
13:19:07 <yongilhe> complex
13:20:18 <yongilhe> and use mem/vcpu like resouce management method help pci better fit to current resource traker
13:20:37 <baoli> yongilhe, I'll take a further look and comment on the patch offline.
13:21:32 <yongilhe> baoli, thanks, and think of this method, it does help us in further resource management like resize, db sync ...
13:22:02 <baoli> yongilhe, sure.
13:22:49 <baoli> anything on the reviews?
13:23:23 <baoli> #topic Blueprints
13:24:01 <baoli> I attended the last nova meeting, and ask for considerations for the BPs we submitted so far. Later I sent an email to the alias for the same.
13:24:46 <irenab> baoli: thank you for pushing it
13:25:03 <baoli> irenab, so yours is rejected
13:25:08 <yongilhe> thanks,baoli
13:25:22 <irenab> baoli: yes
13:25:23 <baoli> We had the similar debate long back, and it came back again.
13:25:43 <irenab> baoli: vnic_type setting?
13:25:47 <pczesno> baoli: is there hope to get anything in?
13:25:50 <baoli> irenab, yes.
13:26:34 <baoli> So one of the concerns is about the CI tests
13:26:39 <irenab> baoli: I think that initially have this setting on network lavel was a compromise, we actually want https://blueprints.launchpad.net/neutron/+spec/api-specify-vnic-type
13:27:22 <yongilhe> baoli, irenab, CI became very ugent thing now
13:27:25 <shaohe_feng> baoli: can I get exception? for the deadline has passed.
13:28:13 <baoli> shaohe_feng, the thing is that it's not us to decide. We need core's sponsorship, and the cores insist SR-IOV is not kilo's priority.
13:28:37 <baoli> So we can only hope and continue our work.
13:28:57 <baoli> yongilhe, yes, so CI is very important
13:29:04 <irenab> baoli: same is for neutron side, but I think we should be more visible on each other blueprint reviews
13:29:18 <yongilhe> i recently push our CI to online, hope we get it soon
13:29:33 <baoli> yongilhe, what kind of tests do you have right now?
13:29:54 <irenab> yonglihe: I saw yout tests on github. Great job!
13:30:19 <yongilhe> basic pci testcases
13:30:29 <yongilhe> irenab, thanks, we had to land some test cases, when it works, we add more
13:30:54 <irenab> https://github.com/intel-hw-ci/Intel-Openstack-Hardware-CI/tree/master/pci_testcases
13:31:09 <yongilhe> irenab, thank it just this link.
13:31:45 <baoli> yongilhe, that's great. Just noticed your stuff on Github.
13:32:03 <yongilhe> baoli， just uploading today
13:33:58 <irenab> I wanted to have short discussion regarding this rejected spec: https://review.openstack.org/#/c/138753/
13:34:11 <yongilhe> irenab, had a question want to consult you.
13:34:15 <baoli> irenab, just thinking the same argument could be used agaist https://review.openstack.org/#/c/138808/6/specs/kilo/approved/api-specify-vnic-type.rst
13:34:58 <irenab> I am worried regarding note from neutron driver team: suggests that you continue to work on building consensus and propose in a later cycle
13:35:20 <baoli> irenab, we implemented https://review.openstack.org/#/c/138808/6/specs/kilo/approved/api-specify-vnic-type.rst initially, but got rejected, and had to create port first.
13:35:21 <yongilhe> irenab, how does your Inc's CI been approved to comments to neutron/nova?
13:36:30 <baoli> irenab, so the basic question is: who is going to be the user, and should he/she be allowed to specify the vnic-type, is this just a backend implementation?
13:36:42 <irenab> yonglihe: please chat with omrim regarding any CI tech details
13:37:20 <yongilhe> irenab, ok, then, i will catch him some day later, thanks.
13:37:49 <irenab> baoli: I actually though we already after this discussion, at least in neutron. We had long discussion during Icehouse time frame
13:39:25 <irenab> I do not think it is backend implementation, but actually request for certain vNIC type
13:39:49 <pczesno> baoli, the user specifies nova boot --nic , so he should also specify vnic_type
13:40:02 <baoli> irenab, I agree. so the assumption is that a cloud allows sr-iov ports and non-sriov-ports to coexist
13:40:25 <irenab> baoli: exactly
13:41:09 <irenab> But I am not sure how we can get  consensus to make some progress
13:41:48 <pczesno> baoli, irenab, i think we should work on providing admin controll via qoutas etc. and use that as a argument to give vnic_type controll to the user
13:41:52 <irenab> pczesno: did you see the objections on the spec I proposed?
13:42:05 <pczesno> irenab, yes i did
13:42:35 <pczesno> irenab, and i agree it's wierd to set vnic_type on logical network
13:42:38 <baoli> the overarching concern is the exposure of vnic_type to the users.
13:43:53 <irenab> pczesno: I think it could improve user experience, but the spec you propose is better option
13:44:23 <pczesno> irenab, yes i agree :)
13:44:42 <baoli> irenab, pczesno, if it's ok to expose the vnic_type to the user, then both proposals are complimentary.
13:44:59 <baoli> that's how I think about it.
13:45:18 <pczesno> baoli, sure, from our perspective
13:45:34 <irenab> the bottom line is that user experice if very unfriendly now, and seems we cannot improve it in Kilo
13:46:43 <irenab> pczesno: is there any work on quota proposal you mentioned?
13:47:00 <pczesno> irenab, i don't think so
13:47:15 <baoli> irenab, pczesno, may be we can look at the flavor proposal again.
13:48:09 <baoli> But in any case, I think that exposure of vnic-type to use is fine. And to compromise, flavor may be enhanced to support vnic_type as well.
13:48:28 <baoli> s/to use/to user/
13:48:50 <pczesno> baoli, if there is no other way, then let's try with flavors
13:49:13 <irenab> baoli: but it is less flexible, since we want vnic_type per --net and not per VM
13:49:43 <baoli> When I look at the offload proposal, it appears to be possible to support the syntax port.? in the flaovr.
13:49:57 <irenab> pczesno: your spec is still under review, so maybe there is some hope
13:50:15 <baoli> irenab, pczesno, I agree it's not flexible, but does address the concerns.
13:50:34 <pczesno> irenab, not much hope i'm afraid
13:50:47 <irenab> baoli: right.
13:50:58 <pczesno> baoli, i think what we have right now is better than flavours
13:51:22 <pczesno> baoli, at least the user can do what he wants
13:51:37 <baoli> pczesno, irenab, may be all of them have reasons to coexist
13:51:56 <baoli> And it may be a way to convince others so that we can continue the owrk
13:52:07 <baoli> s/owrk/work
13:52:41 <irenab> baoli: by flavor you mean VM flavor, right?
13:52:46 <pczesno> baoli, if the spec is not approved i'll try to start a discussion
13:52:49 <yongilhe> baoli， coexist or what ever, does we had good use cases to show, how that is neccessary?
13:53:09 <baoli> irenab, yes.
13:53:43 <baoli> But it's just a quick thought of mine.
13:54:54 <baoli> So let's consider the merits of each proposal
13:55:01 <irenab> baoli: I guess it depends how much work it will require. If it requires nova changes, I think it should worth the efforts
13:56:00 <pczesno> baoli, time is almost up, can we jump to next topic
13:56:05 <pczesno> ?
13:56:09 <baoli> pczesno, sure
13:56:32 <irenab> neutron split?
13:56:39 <pczesno> irenab, yes
13:56:54 <baoli> $topic neutron split
13:56:55 <irenab> I discussed this durng ML2 meeting, got vague answers
13:57:13 <pczesno> irenab, does the MD have to be in separate repo now , or can it stay in tree for kilo?
13:57:18 <irenab> So then discussed on neutrin IRC, and intially it was agreed to keep it in the tree
13:57:29 <pczesno> irenab, ok
13:58:04 <irenab> check here to validate I understood correctly: http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2014-12-17.log
13:58:14 <irenab> Starting at 2014-12-17T18:52:44
13:58:21 <pczesno> irenab, thanks
13:58:32 <irenab> pczesno: np
13:58:40 <baoli> irenab, so all the srioc MDs will stay in tree?
13:59:05 <irenab> baoli: The one which is already upstream
13:59:21 <baoli> ireanb, I see. thanks
14:00:07 <irenab> but I must admit, it is first release I find it hard to understand what is going on in neutron ...
14:00:29 <baoli> Ok, time is up. So we'lll have our next meeting on Jan. 6th.
14:00:43 <yongilhe> sure, bye, everyone
14:01:00 <pczesno> happy new year everyone
14:01:03 <irenab> bye, enjouy the holidays
14:01:28 <baoli> thanks everyone, Merry Christmas and Happy Holidays again!
14:01:34 <baoli> #endmeeting