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