13:04:33 #startmeeting PCI Passthrough 13:04:34 Meeting started Mon Jan 27 13:04:33 2014 UTC and is due to finish in 60 minutes. The chair is baoli. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:04:36 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:04:39 The meeting name has been set to 'pci_passthrough' 13:04:49 #topic SRIOV 13:05:01 Hi 13:05:20 hi 13:05:45 hello! 13:06:41 I updated my comment to Irena's doc about update port 13:07:32 https://wiki.openstack.org/wiki/Meetings/Passthrough#Agenda_on_Jan_27th.2C_2014 13:08:00 sadasu: I see your comment now. I think its specific to the plugin/Mech driver. 13:08:12 my concern was that, ML2 mechanism drivers may not be able to support changing pci flavor after port create 13:08:37 I think PCI flavor should not be changed, agree with you 13:08:45 yes, I want to discuss if it specific to my case or should it be requirement at update port level? 13:08:57 its like VM flavor with PCI alias, no way to change it 13:08:57 same with port config? 13:09:21 yes, I think we should make it clear in the doc also 13:09:40 sadasu: OK, will add clarification 13:09:58 Sounds good 13:10:14 how about profile_id? 13:10:36 sadasu: its specific to your case 13:10:49 if will allow that to be changed, domain xml needs to be rewritten, is that a supported operation in nova? 13:11:03 We need to find out 13:11:14 sadasu: baoli: are you available after the meeting, to take it offline? 13:11:15 renab: agreed....I need to get clarification on any nova constraints so bringing it up now 13:11:22 which doc are we discussing? 13:11:36 Irena's neutron doc 13:11:41 https://docs.google.com/document/d/1RfxfXBNB0mD_kH9SamwqPI8ZM-jg797ky_Fze7SakRc/edit?pli=1 13:11:57 sorry - getting online right at 8:00 EST is difficult due to dropping kids off at school 13:12:28 I was a little late too this morning 13:12:32 rkukura: +1 but we were trying to accomodate several time zones 13:13:10 we were trying to accomodate nova guys 13:13:44 not asking to change schedule - just trying to catch up - should have joined the meeting channel before going 13:14:16 do we have action item on which port settings can be modified with regards to SR-IOV? 13:14:18 #action take a look at nova updating domain xml while the VM is running 13:14:29 baoli: +1 13:14:53 Sorry, little late on the catchup myself. I think the changing of PCI details would be permitted until port attach (since we currently update as part of the attachment process) - shouldn't be changeable once we plug the VIF, basically. 13:14:56 I have no other questions/comments on the doc at this time 13:15:30 sadasu: great 13:15:32 But that would also effectively prevent a knock-on VM spec change after it's started (which is really what we're talking about here) 13:15:55 ijw: exactly 13:16:15 ok. can we proceed with https://wiki.openstack.org/wiki/Meetings/Passthrough#Agenda_on_Jan_27th.2C_2014 13:18:44 I think we had some open action items left over from last Wed's meeting 13:19:12 baoli: I agree with the plan presented here 13:19:29 So the sriov_group would be the thing we pass Neutron to tell if the physical network attachment? 13:19:44 baoli: added 2 comments on the wiki page 13:20:05 And I'm not sure how you avoid pci-flavor but you seem to imply it's possible 13:20:35 irenab, cann't find the comments. Can you paste it here to discuss 13:20:49 just look for irenab 13:21:31 got it 13:21:59 baoli:no major issues 13:22:08 Thanks, irenab 13:22:21 OK, sorry, my connection dropped there and I may have missed a couple of bits 13:22:36 Is there any reason we're passing limited selections to Neutron for the PCI device rather than all its attributes? 13:22:55 It would be great if no work is in the neutron client area 13:23:23 baoli: need to verifu, but pretty sure it will work as is 13:23:28 I need to think about how to use host aggregate for the scheduling issue 13:24:02 irenab, I will take a close look at it too, and list possible items if any 13:24:08 baoli: in what way? 13:24:30 ijw, can you clarify your question? 13:25:04 Are you talking about John's host aggregate discussions or something else? 13:25:10 I don't think they were related to Neutron. 13:25:25 ijw, from the wiki:how do we address this requirement that a compute node may support SRIOV port only, a new filter or enhancement to the existing pci passthrough filter? [irenab - May use host aggregate ] 13:25:43 ijw: no just the way to filter hosts that should accomodate only SR-IOV vNICs 13:25:43 That's what we are talking about 13:26:52 admin should define host aggregate with Hosts that shoud serve the SR-IOV using VMs 13:27:14 OK - I was assuming (not that this is written anywhere) that we'd add a PF attribute to the VF pci_device record, so that you could filter on them in pci_information. 13:27:16 when 'nova boot' is called it will specify Host Agggreate 13:28:02 how to prevent a regular 'nova boot' from scheduling a vm on a host that supports SRIOV? 13:28:19 And then you could make a flavor that specifically calls out SR-IOV devices you're offering up, rather than (at the API level) having to add to a list of hosts with SR-IOV devices, which to my mind would be a bit tricky to get right 13:28:31 irenab, do you require the host aggregate to be used all the time? 13:28:32 Oh, SRIOV only hosts, you mean? 13:28:37 Yeah, I would go with that for now 13:29:00 baoli: no, just for now if this requured 13:29:16 another option, not to run there any vSwitch 13:29:29 so port-binding will fail 13:30:00 and VM will be booted on othe Host 13:30:10 irenab, if we are talking about the short-term goal, sure, we can avoid this requirement 13:30:29 agree with a short term goal 13:30:33 Port binding would fail, but we want to avoid scheduling there so that doesn't happen 13:30:36 baoli: currently talking the short term 13:31:18 this scheduler problem does relate to host itself. 13:31:20 I guess we are back to neutron-aware-scheduler, but its for Juno, yes? 13:31:44 irenab, yes. So we don't want to support coexistence of SRIOV-only and non-SRIOV compute nodes initially 13:32:06 I actually think we should, why not? 13:32:23 Sorry for being 1/2 out of the loop, but isn't the idea for juno to use host aggregates to give the user a way to force the scheduling? 13:32:41 Sorry, my network hates me today 13:32:56 rkukura: I think Host aggregates may be used already now 13:32:57 irenab, then we go back to the same issue. 13:33:20 baoli: can you please clarify the issue 13:33:32 What I was trying to say is that if this is a use case then it's not in the use case list at the moment. I'd like to add it, I think host aggregates are the right way to do it if you want to have hosts dedicated to machines needing SRIOV but I would also like to know how important it is 13:34:22 I think the coexistence of OVS + SRIOV is more important 13:34:26 agree, and this request seems does not impact pci scheduler. 13:34:29 #issue,coexistence of SRIOV-only and non-SRIOV compute nodes 13:34:56 I think baoli's case is that if you have only a very few SRIOV capable hosts it's a good idea to avoid using them for machines that don't need SRIOV facilities - that about right? 13:35:04 baoli: what issue do you see when coexistence should be supported? 13:35:16 Presumably nova API lets you specify a specific host aggregate. But is there a way to exclude certain host aggregates from being used when no aggregate is specified via the API? 13:35:17 ijw, that's right 13:36:04 nova boot --flavor 1 --image --nic net-id=net vm 13:36:25 if host 1 supports sriov only nic, host 2 supports non-sriov nic, 13:36:44 you don't want 'vm' to be running on host 1 13:37:00 OK - then I see your point and it sounds to me like it's a thing that would best be served with a better scheduler filter, but for preference I would add another BP later. It could easily be implemented as an independent filter that deprioritises hosts with SRIOV devices. 13:37:24 Make sense? 13:37:54 ijw, not sure. the filter basically works the same as the existing PCI filter, with some new constraints added 13:38:02 set host aggregate like 'sriov-only' propery and then set key in instance flavor, this solve the problem, this is supported now, right? 13:38:19 ijw: Sounds like we want nova to never schedule onto an SRIOV aggregate unless that aggregate is explicitly requested, right? 13:38:45 Well, technically it's working on VMs that *don't* have passthrough requirements, which is not quite the same as the current one, which pretty much only affects scheduling for VMs that *do*( 13:38:49 rkukura, so the aggregate does has this for now. 13:39:52 so if some deployments want to disable coexsistanse on SR-IOV and non SRIOV cnic, it will be possible with Host Aggregates 13:39:54 Host aggregate is a less automatic way of doing it (either way you have a host aggregate you add SRIOV capable hosts to or one that you add non-SRIOV capable hosts to) but it does mean that even without explicit code to serve the case you could get something working, which is another reason why it's not a huge priority 13:40:21 ijw: agree 13:40:57 I think the coexistence case is quite important, since same VM may have different NIC types 13:41:13 Indeed - so this is really about avoiding SRIOV hosts when you have no SRIOV needs 13:41:37 ijw: exactly 13:41:49 Well, let's take another thread to discuss this offline, and decide in a later IRC meeting. It's quite clear what the requirement is 13:42:02 baoli, cool 13:42:20 baoli: fine 13:42:23 I'll start the thread after the meeting 13:42:29 baoli: yeah - I'd just like to agree this isn't a release 1 issue, that's all - it doesn't seem to block what we're doing now 13:42:43 ijw: +1 13:42:56 ijw, that sounds fine to me 13:43:25 Any more comments to the plan? 13:43:35 all good 13:44:14 baoli: need to see that all parts have owners 13:44:23 irenab, yes. 13:44:28 As it stood, I think it was: 13:44:40 heyongli: pci_information initially, then pci_flavor_attrs (?) 13:44:42 basiclly i will take all in extra_info blue prints. 13:44:48 irenab: Neutorn 13:44:48 ijw: scheduler 13:45:14 baoli: CLI and API changes 13:45:25 ijw: sure, i take that definitely, 13:45:33 ijw: for neutron we have general part for ML2 and NechDriver for Cisco and Mellanox 13:45:49 and pci flavor, DB, object and API , we had another guy for this 13:45:58 I am on general part right now 13:46:08 Let's start with nova part 13:46:22 baoli: VIF DRiver is yours? 13:46:38 I can do that too, up to you - tell me what you need 13:46:39 irenab, not a problem. 13:46:50 ... but obviously I prefer giving baoli all the work ;) 13:47:26 will probably need a way to coordinate, so please be on IRC when available 13:47:35 heyongli: I think I'm going to need your work to do scheduling so when you get your patches up drop me a mail directly 13:48:02 ijw: patch is quickly release, i think. 13:48:07 Cool. 13:48:33 Yeyongli, so do you agree with the SRIOV items in nova 13:48:37 cause i had most of them alredy, and i re-assmeblem them according bp 13:48:41 Also, I'm in the middle of relocating, so this week might be a bit crap. Don't think you'll see code from me till next week regardless 13:48:48 baoli, sure 13:49:33 baoli, in detail code interface, catch me or yunhong in any time 13:49:43 If I am not mistaken we have time till Mid February to lend code upstream to give it a chance to enter Icehouse 13:50:10 irenab, it's risk 13:50:19 especially nova part 13:50:24 heyongli, sure. Especially I need the marker thing we've discussed 13:50:52 baoli: sure, let's talk it in mail thread 13:51:52 heyongli, sure 13:52:21 so seems we can back to weekly meeting? 13:52:41 irenab: Mid-Feb for approval, yes, but we need to make sure that we get our patches up and reviewable so that there's time for people to check them 13:52:54 and i will on vacation from Tuesday, yunhong will cover me. 13:52:55 ijw: agree 13:53:04 Sounds like we're on track for that now, mind you, but don't put them up 5 days before ;) 13:53:28 So let's make it clear who is doing what. 13:53:28 ijw. i kind of worry the nova bp and nova review process. 13:54:00 There's the open question of PCI flavors, I think, versus John's host aggregate suggestion. 13:54:19 ijw, also the issue I raised in last IRC meeting 13:54:30 heyongli: I think we'll make reasonable process if we have consensus 13:54:33 baoli: what was that? 13:54:53 ijw, I guess that you didn't take it seriously 13:55:09 baoli: I wasn't there on Thursday and haven't checked the minutes 13:55:32 ijw, sorry, the issue I raised on Wednesday, I guess 13:56:11 remind me? 13:56:44 so are we still having meeting on daily basis? 13:56:52 passing the attr list back and forth? 13:56:56 you agreed to clearly specify how the pci stats works: in terms of how compute nodes get the knowledge of pci attributes, pci flavors, and update the stats, what stats buckets are, etc 13:57:25 baoli: Then I moved out of the Netherlands - so yes, I didn't take it quite as seriously as doing that, that would be fair ;) 13:57:42 You're right, it needs doing, let me spec it up 13:57:56 Let's have one tomorrow, and then go back to normal schedule unless something urgent comes up 13:58:04 sure 13:58:17 ok 13:58:34 I'm still not very clear who's doing what. Let's make it clear tomorrow 13:58:38 heyongli: I'll forward that spec to you, it's all tied up with the backend stuff 13:58:58 baoli: list is up there ^^^ 13:58:58 ijw: please send to all 13:59:16 ijw: for me , i think it no suprise, anyway, let's discuss 13:59:37 ok, we'll meet again tomorrow? 13:59:51 sure 13:59:55 Thanks everyone 13:59:59 sure, and have list of items with owners? 14:00:04 yes, we should 14:00:19 Sure. Let's start with email today? 14:00:27 #endmeeting