13:01:09 <baoli> #startmeeting PCI Passthrough 13:01:10 <openstack> Meeting started Tue Apr 8 13:01:09 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:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:01:13 <openstack> The meeting name has been set to 'pci_passthrough' 13:01:23 <beagles> o/ 13:01:28 <baoli> hi 13:01:34 <irenab> hi 13:01:40 <heyongli> hi,all 13:01:50 <boh_ricky> hi 13:02:47 <baoli> We can continue from last week about the use cases and the etherpad that Irenab created. 13:04:34 <irenab> baoli: I added etherpad link to the session proposed by you 13:04:47 <heyongli> how far we'd go to make use case meet everyone's requirements? 13:04:54 <baoli> irenab, great, thanks 13:05:28 <irenab> heyongli: what do you mean? 13:06:01 <heyongli> i mean when we close use case discuss, what is should look like? 13:07:24 <irenab> heyongly: I added a table for use case coverage. If its OK by everyone, I think we will have the flow description and needed APIs 13:07:51 <baoli> Heyongli, the debate regarding your use case seems to be: 1) should vendor_id/product_id be exposed to the admin/user, 2) single tag versus multiple tags 13:07:54 <irenab> there is also assumtions that may cover design decisions 13:09:00 <baoli> irenab, your table is a good start. I think it has a good coverage on networking sr-iov. 13:09:04 <heyongli> baoli, yeah, 13:09:44 <baoli> heyongli, I agree to have multiple tags 13:10:02 <irenab> baoli: Thanks. Now we should fill the tables. I think we need decision if we go with Flavor approach 13:10:09 <heyongli> happy to know this, this is important to me 13:11:06 <baoli> heyongli, but how to implement them in terms of API, user interface, is a different matter. 13:11:23 <heyongli> sure, what do you think it should be? 13:11:39 <irenab> I think we need to define it as part of use case coverage. Agree? 13:11:49 <baoli> heyongli, let's focus on the use case and requirements first. 13:12:41 <heyongli> baoli, i agree the format, and it can be filled offline 13:14:10 <heyongli> baoli, hope you could add https://blueprints.launchpad.net/nova/+spec/pci-extra-info to joint session design topic:http://summit.openstack.org/cfp/details/248 13:14:52 <heyongli> irenab, to cover the api, we need a interface agreement, or at least some proposal 13:15:24 <baoli> heyongli, sorry that I missed that. I will add it 13:15:28 <irenab> I started to fill in the first use case and quite stuck for flow description, since it should cover what admin is going to define. 13:16:30 <irenab> shall we progress with existing constructs (flavors) or switching to groups? 13:16:48 <irenab> we can evaluate both approaches and present both.... 13:17:00 <heyongli> irenab, for mult tags, how groups would look like? 13:17:52 <irenab> heyongli: I think baoli can define it. I must admit, not quite sure how it should work 13:18:13 <baoli> irenab, when you talk about flavor, can you clarify what's exactly in your mind? 13:18:39 <irenab> quite based on https://docs.google.com/document/d/1vadqmurlnlvZ5bv3BlUbFeXRS_wh-dsgi5plSjimWjU/edit?pli=1# 13:18:53 <irenab> PCI Flavor that can be associated with vNIC 13:19:19 <heyongli> cause we decide expose multi tags, so the user interface had 2 choice: the flavor , or just use the instance flavor extra information to hold the specs. 13:19:20 <baoli> irenab, ok 13:19:53 <irenab> heyongli: when you say flavor, you mean VM flavor? 13:20:01 <heyongli> pci flavor 13:20:05 <irenab> or PCI flavor 13:20:17 <heyongli> i refrence the VM flavor as instance flavor 13:20:27 <irenab> heyongli: got it, thanks 13:21:15 <heyongli> the later choice, hold the specs in instance flavor most like baoli solution, right, it elimate the need of new set of APi, 13:22:54 <irenab> heyongli: not sure, but I think you mix the API and internal implementation. We must have API to associate PCI device per VM VIF 13:23:39 <heyongli> irenab, i think you talk about like --nic things 13:23:52 <irenab> and here is another question I raised in the etherpad if we need vNIC flavor or PCI flavor is enough 13:24:04 <irenab> heyongli: right 13:25:06 <heyongli> i don't refer to --nic thing, i mean we can define pci flavor via a set of new API or use instance flavor's exist api to achieve something liek boali's approach 13:26:03 <heyongli> and there is a set of ops available, refer to from nova.scheduler.filters import extra_specs_ops 13:26:25 <irenab> heyongli: let's ask baoli what he means :-) 13:26:26 <heyongli> we can use this as 'bare' pci flavor 13:27:03 <heyongli> baoli, ping you about this , this seems will work 13:27:38 * johnthetubaguy notices summit session, wonders what the plan is, continues to lurk 13:29:04 <irenab> johnthetubaguy: hi 13:29:07 <heyongli> johnthetubaguy, baoli register a joined session, discuss all in that one, i just wonder if the time is enough, 13:29:14 * johnthetubaguy also wonders if they have tried drafting some nova-specs 13:29:35 <johnthetubaguy> I think agreeing the user goals with everyone would be good, just to share the ideas 13:29:50 <johnthetubaguy> would be good to present implementation ideas, but that might need a cross project session 13:30:15 <irenab> johnthetubaguy: we are working on this doc: https://docs.google.com/document/d/1zgMaXqrCnad01-jQH7Mkmf6amlghw9RMScGLBrKslmw/edit# 13:31:09 <irenab> this should cover use cases both for admin and tenant users 13:33:09 <johnthetubaguy> irenab: OK, but the nova-spec would be needed in the end, might help for the summit, just to frame the discussion in the "standard" format, but clearly any agreement is better than none 13:33:24 <johnthetubaguy> just wondering how to stop information overload during the summit session, like last time 13:34:44 <irenab> johnthetubaguy: Agree. Any suggestion? I think nova-specs will be created quite easily once agreement is reached 13:34:51 <baoli> johnthetubaguy: out of this discussion, i think we should come up with the standard nova-spec. 13:35:19 <johnthetubaguy> yeah, just I think you already agree on 90% of the nova-spec 13:35:26 <johnthetubaguy> its the defining the problem and use cases, etc 13:36:03 <johnthetubaguy> irenab: focus on use cases, I guess, at least at first 13:36:11 <irenab> johnthetubaguy: is there any deadline for nova-specs? 13:36:31 <irenab> is it manadatory for the session to be accepted? 13:37:02 <johnthetubaguy> irenab: no deadline yet, no ptl elected yet :) 13:37:52 <irenab> I can port the use cases doc to the nova-spec, but we still discuss the APIs and model objects (Flavors, groups, ...) 13:39:22 <johnthetubaguy> OK, use cases would be a top starting place 13:39:37 <johnthetubaguy> sketch of API would be good too, but agreed, thats still contentious 13:39:51 <johnthetubaguy> hows the "data model" going, to you agree on the information flows yet? 13:41:00 <heyongli> at least we agree on there should have multi property for a pci device 13:41:38 <irenab> I think the main gap is in APIs/Config area 13:42:14 <johnthetubaguy> ah, OK 13:42:50 <baoli> With multiple tags in mind, we can go over the use cases, and see how it can be applied to each 13:42:54 <heyongli> this is pci information provisioning, user interface still discuss , but there is at least 2 option we can choose 13:43:28 <johnthetubaguy> my take would be agree the information flow 13:43:33 <johnthetubaguy> then worry about API vs config 13:44:04 <johnthetubaguy> so, what does the VIF driver need to attach, what does the user think about, what does the admin think about and specify, etc 13:44:17 <johnthetubaguy> like use cases, but this data packets 13:44:30 <johnthetubaguy> then its much easier to argue about the API vs config options 13:45:32 <baoli> johnthetubaguy, that's the purpose of the doc https://docs.google.com/document/d/1zgMaXqrCnad01-jQH7Mkmf6amlghw9RMScGLBrKslmw/edit#. 13:46:10 <irenab> just for exmaple, lets take the first use case: admin sets groups of devices that can be allocated. 13:46:51 <irenab> we need to define what had to be done on Cotrooller/Compute nodes, right? 13:48:00 <heyongli> for the information flow, whitlist/pci information for provisioning and pci stats for summary to scheduler, seems we agree on this. any objection? we agree on a flow then know what should be done in compute node and controller separately 13:48:40 <johnthetubaguy> yeah, OK, need to find a nice way to present the info to people with no idea about SRIOV 13:48:44 <johnthetubaguy> sounds like you are almost there 13:49:16 <irenab> So we are ready to go to upper level and specify the APIs /config admin should use 13:50:26 <Hao> there was a short discuss in mail loop proposing VFIO. 13:50:47 <johnthetubaguy> OK, I don't see any details in the doc about the information flow, but I could have missed it 13:51:09 <irenab> heyongli: by the way I am still not sure if we need PCI alias/flavor on controller for networking case.... 13:52:00 <johnthetubaguy> I think you should start with the "tenant" stories, BTW 13:52:08 <heyongli> irenab: that come from both sriov and common pci use case, as one of solution 13:52:19 <johnthetubaguy> once its clear what the user needs, it makes it easier to understand the admin stuff, but that might just be me 13:53:00 <irenab> johnthetubaguy: I think you are right 13:53:15 <irenab> hao: I remember I saw the email. Can you please add some details? 13:53:43 <johnthetubaguy> irenab: its that stuff that I think will help in the summit session, getting peoples head straight about the user problems that need solving, then delving deep 13:54:09 <heyongli> johnthetubaguy, that's value to all, but fill the information flow in the use case need some agreement, am i right? 13:54:09 <baoli> Can we do this: with each use case, figure out what tags will be needed, and how to use the tags to achieve it? 13:54:47 <Hao> it was proposed to use vfio to detect pci passthru and sriov. i think it would be a nice idea. 13:55:05 <heyongli> baoli, agree, just think, you describe the 'how to use it' like should get a use interface there 13:56:02 <irenab> baoli: I think we can, but it is relevant for admin use cases. I think we better follow John suggestion and focus on tenant first 13:56:06 <heyongli> hao, not sure you detect means, but like another story to say 13:56:59 <baoli> heyongli, let's give it a try. 13:57:30 <baoli> irenab, sure. 13:57:39 <irenab> can we try to put more details in tenants use cases and maybe add few (I think sadasu has some more) in coming days? 13:57:56 <heyongli> baoli, sure i need a example to continue that without a interface 13:58:11 <johnthetubaguy> irenab: +1 that approach, more tenant details, make it clear what their abstractions are 13:58:41 <baoli> irenab, let's work on that. 13:58:47 <sadasu> irenab: +1 13:59:16 <irenab> baoli: great. If you can add some today, I'll continue tomorrow 13:59:41 <heyongli> follow this way 13:59:42 <baoli> irenab, sure. 13:59:44 <irenab> We can cover for 24 hours :-) 13:59:59 <baoli> Thanks everyone. 14:00:06 <baoli> #endmeeting