14:01:26 #startmeeting PCI passthrough 14:01:27 Meeting started Tue Dec 10 14:01:26 2013 UTC and is due to finish in 60 minutes. The chair is sadasu. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:31 The meeting name has been set to 'pci_passthrough' 14:01:55 hi 14:02:33 At this point, I'm not sure what our agenda is going to be for today. But I Just saw the email from Yongli about the PCI flavor design. Can anyone tell who are involved in it? 14:02:53 Is yongli around? 14:03:55 baoli: I tried to catch up on PCI flavor design today, but quite confused with what is going on there 14:04:18 baoli: I get some information from yongli, a core developer in nova think the alias/whitelist is not the right solution, and should use the host aggregate for it. 14:04:41 baoli: I'm busy on another task these two weeks, so didn't get into details. 14:04:48 yjiang5: could you pls explain further? 14:04:48 irenab: what's the confusion? 14:05:23 yjiang5: how it solves the PCI for networking 14:05:32 For the 10 minutes worth of reading, it seems to me that pci-flavor, in concept, is similar to pci-group. But configuration of compute nodes for PCI is done with the a nova PCI 14:06:07 irenab: I don't think it's for PCI networking specific, but generic PCI changes. 14:06:50 nova pci-flavor-create name 'GetMePowerfulldevice' description "xxxxx" 14:07:05 sadasu: I have no time to check the details yet. 14:07:20 nova pci-flavor-update UUID set 'description'='xxxx' 'address'= '0000:01:*.7', 'host'='compute-id' 14:08:02 So the API seems to be combining the whitelist + lci-group 14:08:02 does PCI flavor take care of letting nova know of the "feature" associated with the PCI device? 14:08:18 @sadasu, don't think so 14:08:38 PCI flavor still should be part of the VM flavor, right? 14:09:06 I think so. 14:09:36 We should brought John's attention to our effort, and we should combine the ideas and converge 14:09:49 baoli: agree 14:09:59 irenab: I think PCI flavor will be like alias, to be used in VM flavor 14:11:03 yjiang5: thas what I understood too. I do not like it, since its not flexible for nic addition for running VM 14:11:45 @yjang5, seems like that you guys are aware of John and Yongli's effort on pci-flavor. Just wonder why we are in the dark. 14:12:11 there seems to be a huge overlap of our effort with them 14:12:36 baoli: I think the reason is because John is the core deverloper review the BP that discussed in this meeting, and object it. 14:12:56 baoli: I just saw Yongli comments on the mail today referensing wiki 14:13:12 @irenab, same here 14:13:38 baoli: I think we need to commmunicate on the the devs mailing list and have one place discussion 14:14:01 irenab: agree. 14:14:17 I completely agree. 14:15:20 irenab: I think this change should not impact network effort from API point of view. 14:15:51 yjiang5: agree, from neutron API point of view 14:16:26 @yjang5, I think that when designing the nova part of the PCI passthrough, folks working on networking/storage, a.k.a, feature, should get involved 14:17:37 baoli: thanks for remind and agree. We will send mail to mailing list for this talk. Sorry for it. 14:18:04 Especially we have something in disucssion ourself for so long 14:19:12 baoli: Do we want to discuss what to send out to the mailing list? 14:20:28 @irenab, absolutely. But I need some time to completely absort the material. Maybe we can exchange email first after reading it? We can also use time here to discuss it 14:20:49 baoli:agree 14:22:39 I would like to understand the request binding pieces to see what information can be assumed to be available to the neutron on port creation 14:23:12 Yes. 14:23:50 Then I think it can be possible to define the neutron part assuming noa and scheduling details will be finalized 14:24:03 baoli: irenab:agree. 14:25:00 How do you guys think about adding devices per compute node by means of a nova API? 14:25:20 nova pci-flavor-update 14:25:40 Also, we need to find out if the compute node still needs to configure the whitelist 14:25:40 baoli: I think at can be in addition to auto-discovery 14:26:22 @irenab, that would sound ok 14:27:55 the config file for alias and whitelist defination is going to deprecated. if database is not NULL , configration is ommit and given deprecated warning. if database is NULL, config if read from the file, 14:28:05 from the wiki 14:28:15 with this solution, we move pci config from file to API. 14:28:22 also from the wiki 14:29:07 baoli: do you agree with deprecating config option (white-list)? 14:30:37 we had a discussion on this during the summit. But later I thought that using a centralized API to manage ocmpute nodes resources doesn't sound right to me. But it could be an additon if dynamic change is needed 14:31:23 baoli: I remember yongli told me that the API is requested in the summit discussion? 14:31:54 @yjang5, yes, I had a conversation with Yongli on that as well. 14:33:52 another concern I have is regarding PCI request as part of the VM flavor 14:34:13 With the API, does nova api needs to notify nova-compute for the resouces that it owns, where the actual allocation occurs? 14:34:57 irenab: I think PCI flavor can also be used for neutron? For example, neutron can create flavor first, and then use it onport creation? at least we can extend it to work this way. 14:36:05 I think it will make VM provisioning flow very complicated 14:36:59 yjiang5: for every combination of VM with networks, admin will have to define different flavors 14:37:49 irenab: you mean we need one extra effort? Currently we can specify the alias directly , right? 14:38:15 yjiang5: ideally, I think it should be possible to create VM with several vNIC each one either using PCI device or OVS for example 14:38:43 @irenab, also we 14:38:59 we'd like to use network xml to support live migration. 14:39:11 where the allocation of devices happen in libvirt 14:39:41 we have to keep that in mind 14:39:53 baoli: agree, once nova supports it 14:40:44 irenab: baoli what do you mean of allocation of devices happen in libvirt? 14:41:01 @irenab, I may be wrong. But that plays into on what basis, a network xml should be defined. We used to think mapping PCI group to a network xml 14:42:15 @yjing5, with network xml, libvirt allocates a PCI device out of those included in the 'network' 14:42:45 what I meant to say that putting PCI devices request in flavor is very unflexible. Admin may want to specify on VM creation what vif-type he requires per Network. 14:43:10 @irenab, I agree with you on that 14:45:19 irenab: so you mean if use pci flavor, we have to create flavor for each such VM creation request and is not convenient, am I right? 14:45:52 irenab: instead, we should simply passing all parameter in the creation request directly, right? 14:46:03 yjiang5: I mean VM flavor 14:47:16 yjiang5: the new wiki gets rid of pci alias which is good because we have been asking for it for a while 14:47:37 but it is making an assumption that all SRIOV devices are equivalent 14:47:46 like in a neutron port 14:47:54 but that is not the case 14:48:40 SRIOV ports will have to be put into diff flavors based on the physical network that they are connected to and other config that we want to apply on them 14:49:17 so the number of flavor creation requests could be significant 14:49:20 @yjang5, can you tell us John's full name and his email? 14:49:58 baoli: I think he comments on the BP and then yongli discussed with him on the IRC. 14:50:06 baoli: let me check 14:50:59 also, configuring the flavor via neutron using Nova API requires Neutron to know so much more about the network config that we had not initially planned on 14:51:17 so this might affect our design significantly 14:51:18 baoli: I think John Garbutt and possibly we should initiate the discussion on the mailing list. 14:51:54 @yjang5, thanks for the info. 14:52:18 I just resurrected the old thread...could you please reply to that? 14:52:26 sadasu: I think its not even possible to create flavor from neutron 14:52:41 Let's exchange comments/concerns with email, then we'll summarize it and send it to the openstack alias, in the same time bringing John's attention to our effort. The goal is to converge 14:53:22 baoli: agree 14:54:27 lets try to push it soon, since Yongli probably starts to code to make something into icehouse-2 14:54:58 Agreed. So let's continue through emails 14:55:15 baoli: fine 14:55:47 baoli: ok 14:56:16 Thanks everyone. 14:56:21 thanks 14:56:24 thanks. 14:56:30 thanks 14:56:38 #endmeeting