13:05:06 #startmeeting PCI passthrough 13:05:06 Meeting started Tue Mar 25 13:05:06 2014 UTC and is due to finish in 60 minutes. The chair is baoli. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:05:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:05:09 The meeting name has been set to 'pci_passthrough' 13:05:56 Hi 13:08:06 Hi heyongli 13:08:09 hi 13:08:27 hi 13:08:33 Hi Irenab 13:08:56 sorry being late, didn't pay attention that was disconnected 13:08:58 We can start with irenab's doc on use cases 13:09:17 sure 13:09:28 https://docs.google.com/document/d/1zgMaXqrCnad01-jQH7Mkmf6amlghw9RMScGLBrKslmw/edit 13:09:41 hi - I’m here, but not able to pay 100% attention 13:09:58 rkukura, thanks for getting up early 13:10:13 woke up at 4:00 AM 13:10:31 too early for you 13:10:50 rkukura: appretiate it 13:15:31 I was about 9 mins late 13:15:37 not sure what was discussed 13:16:00 sadasu, https://docs.google.com/document/d/1zgMaXqrCnad01-jQH7Mkmf6amlghw9RMScGLBrKslmw/edit 13:16:07 I can't gather context from the last 5 mins that I am logged in 13:16:52 Any comments on the doc? 13:17:16 sadasu: discussion on use case doc 13:18:03 I need we need to add information on why and how device selection happens 13:18:15 I think that would be part of the use case 13:18:23 first things, this is for sriov use case, i'm ok with sriov use case, and for support sriov, there need some other use case to be considerated, and i like to put them to nova side bp for common support 13:18:41 sadsu: it is just initial doc to put the list of use cases, we can then enter into more details 13:18:56 so nova side support be common , include the sriov use case 13:19:30 ireanb: agreed…just giving input on what can be added next 13:20:03 heyongli: yes, we can add non-sriov use case too 13:20:20 sadasu, i don't mean add them to this doc 13:20:26 heyongli: agree with you. I just feel that SR-IOV networking devices have quite special use cases 13:20:48 heyongli: just re-read….lets not spread out info in diff places 13:20:51 i like to keep the sriov case as sriov, just ensure common pci design can support this 13:21:07 we had originally discussed that we will capture all use cases in one place... 13:21:44 you can dive into a lot of depth in a diff doc but lets at least capture all use cases in one place 13:21:59 sadasu: I thought we mean SR-IOV/networking use cases 13:22:09 i just think, sriov discuss get sriov use case clear, 13:22:17 yeah, irenab, +1 13:23:04 pci changes should also keep common pci use case move forward, and i'm here hope to make the pci common part support SRIOV 13:23:21 after going into details on updated nova bp, I think it has enough details both for generic and SR-IOV use cases 13:23:22 don't you think at least the top level use cases should be in one place to give the impression we work together? 13:24:11 sadasu: I think Heyongli's bp includes SR-IOV cases from nova perspective 13:24:38 ok…I am lost here... 13:24:46 but for example mettering use case is something special for networking and not related to nova at all 13:24:53 I understand that this information exists in other places... 13:25:06 sadasu, to prevent icehouse's endless discuss keep going, i very want the discussion and work can be parttion easily 13:25:13 I thought we are coming up with a way to present during the summit... 13:25:29 maybe we need to return to the initial intention form setting new doc to capture SR-IOV use cases 13:25:48 ^for 13:26:12 I thought we are having a generic nova/neutron joint session where we discuss top level use cases, SR-IOV and non-SR-IOV 13:26:30 put it in a format that would eventually end up in an etherpad 13:27:04 then we dive into a lot more detail for SR-IOV in a neutron session and non-se-iov case in nova session 13:27:06 i doubt and worry a big design will block the process 13:27:49 Do you think non networking SR-IOV case needs discussion? 13:27:55 exactly for that reason, please don't start with splitting because this big design will affect all use-cases 13:28:19 seems the most challanges and requests for changes come from networking cases 13:28:56 sadasu: please suggest how to proceed 13:29:11 irenab: I am predicting we will have a big discussion about flavor, host aggregate 13:29:12 sadasu, the design won't impact the use case, the use case impact the design might, so it might ok to keep them split and less couple 13:29:38 lets get this taken care of first..that was the biggest blocker for Icehouse 13:30:29 for that discussion to happen, lets capture all use cases in one place at high level 13:30:37 I think I understand sadasu's concern. Need to take into account both non-networking and networking use cases to impact the overall approach 13:30:42 agree, but do we already agree the flavor should be there? and for aggregate , it's might be the holder of flavor. 13:31:02 after that point, we can split it and get into more detail for sr-iov 13:31:09 agree for the biggest blocker 13:31:44 should we focus on individual use cases, document them one at a time. and then we can decide to put them together or not. 13:31:54 I am not picking an approach here…I think we should present them all 13:31:56 baoli: +1 13:32:38 irenab, in that regard, I felt that the doc should provide detailed use cases. 13:33:14 baoli: agree, it was the initial version to put the list of use cases that should be covered. 13:33:40 to prove that a particular solution that we are presenting is taking care of all use cases, we should put them all together and present together 13:34:27 Also, I don't think reference to flavor is appropriate because use cases are better not to be tailored to specific implementation at this point. 13:34:28 by particular solution I am specifically talking about flavor and host aggregate debates again 13:35:07 baoli: agreed.. 13:35:34 irenab: the doc is talking about flavor in the use cases when that is actually part of a proposed solution 13:35:47 I used term flavor for abstract definition for different categories of devices, just didn't find better name 13:35:48 i more prefer revise current design, no revolution current design so i prefer a graduate way to achive that,if possible 13:36:03 we are actually just looking for a way for the admin to specify a group of devices that satisfy a specific criteria 13:36:42 guys, the doc is open for editing, so all can add more use cases or modify 13:37:31 irenab, so start with a good format to present each use case and people can start adding. 13:38:04 I admit to being a bit confused. Is there a particular issue with what sadasu is saying? Also is there a particular issue with using irenab's document as a starting point? I feel I am missing something 13:38:05 its possible to add gloassary for the doc and explain that flavor is group of devices that satisfy a specific criteria . Would it do the job? 13:38:49 beagles: no issue with irenab's doc 13:39:07 I would agree that it would be best if we were "armed" with ideas and information on how respond to hard questions about impacts and how it is all going to hang together 13:39:14 on the other hand there is a proposal to split use cases into 2 separate docs 13:39:33 so pushing to capture all of them in irenab's doc 13:39:51 irenab, that's might just be current flavor? it can not avoid to say how to specify 'criteria' things 13:40:22 For example, heyongli talks about a use case in one of his recent emails: an image only runs on a certain hardware from a particular vendor. 13:40:26 heyongli: yes we can talk about flavor in the design section... 13:40:36 oh.. ahh... mmmm why would we want to do that? We can certainly assemble them into something comprehensive... if they don't mesh, my "feeling" is that we would be missing something. 13:40:54 sadasu, not just split to 2 docs, i kind of prefer non use case don't impact sriov, if possible, might small bp to achieve our goal. 13:40:55 heyongli: I think baoli want to keep the description without stating the approach 13:40:58 kind of a naive and vague point of view... I know :) 13:41:00 not while specifying use cases…because potentially that problem can be solved in multiple ways, flavor being one of them 13:42:00 beagles: agreed 13:42:10 so the format can be: name, summary, detailed description, if necessary a diagram for illustration purpose. 13:42:53 baoli: +1 13:43:03 baoli: I'll add the format according to the traditioanl UML use case template, we can drop what is not relevant. Will do it after the meeting 13:43:22 irenab, that sounds great! 13:44:13 heyongli: how the BP pans out is different from a consistent design, don't u think? 13:44:17 I hope that people can start adding/commenting to the doc. 13:44:26 Does some one has more use cases to add or any suggestion on doc organization? 13:44:27 beagles : +1 13:45:08 ireanb: VM with high throughput, no live migration 13:45:25 VM with medium throughput, with live migration 13:45:50 irenab, I have some vague ideas on doc organization, but I'd like to ruminate a bit and maybe throw some ideas around instead of wasting meeting time 13:45:51 VM with mixture of SR-IOV port +PCI passthrough storage device 13:46:29 VM with one SR-IOV port with regular non-SR-IOV port 13:46:31 I had a similar issue with the parity work.. a bunch of disjoint pieces spread all over and followed a bunch of ways. I could never find a way that I felt wasn't awkward as hell 13:46:56 baeagles: would be great 13:47:27 beagles: +1 13:48:17 ireanb: until we figure out the final format, we can add the list of use cases in your doc 13:49:04 so recap: we'll finalize the doc organization, and then people add/comment use cases into the doc. 13:49:06 sadasu, yeah.. I think right now it would be good to keep things in one place and then break out and organize. It is easier than going the other way, where things might get missed 13:49:11 sadasu: great 13:50:51 I think the non networking use cases can be in nova bp for now, at least till we figure out the details of networking SR-IOV related use case. 13:51:47 heyongli: what to you think? 13:52:14 i just don't know if one big design will get core's attention 13:52:58 my feeling was that non networking PCI staff was already in and we want to add networking use cases support 13:53:23 can't agree with you more irenab 13:53:40 but it can be good to see all use cases defined anyway 13:54:26 non networking stuff also need improve, i just don't want it to be part of sriov, but i do like you can take that as a factor 13:55:42 in this phase would it have to be more than a mention of how they don't interfere and are handled in a consistent fashion.. and maybe that it would be a valid test point? 13:56:03 so next step, I'll add template for use case description, anyone adds use cases that are relevant. Am I right? 13:56:16 yes 13:56:19 s'cool with me 13:56:28 cool 13:56:43 also fine to me 13:56:52 great 13:57:25 baoli: wanted to check if you plan some further work on your nova patch till Juno summit 13:58:06 in case something changed in our discuss, any patch update seems ... i don't know that 13:58:09 irenab, I don't have a plan yet. It purpose is to facilitate integration with neutron 13:59:17 heyongli, please take a look at https://review.openstack.org/#/c/82206/ when you have a chance. 13:59:22 I think it can help to promote it to Juno, nova parts take a lot of time to get in 13:59:51 baoli, i look at it today but not feedback yet 14:00:01 i will spend more time on it 14:00:17 heyongli: what little BP were you talking about earlier? 14:00:22 heyongli, thanks. we need to come up with a resolution. 14:00:46 sadasu_, i want to split big bp to small one, if possible 14:00:56 in my plan 14:01:32 time is up. I have to end this meeting now. Expecting to see the use case doc format so that we can start contributing. 14:01:38 #endmeeting