13:04:33 <baoli> #startmeeting PCI Passthrough
13:04:34 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:04:39 <openstack> The meeting name has been set to 'pci_passthrough'
13:04:49 <baoli> #topic SRIOV
13:05:01 <baoli> Hi
13:05:20 <irenab> hi
13:05:45 <sadasu> hello!
13:06:41 <sadasu> I updated my comment to Irena's doc about update port
13:07:32 <baoli> https://wiki.openstack.org/wiki/Meetings/Passthrough#Agenda_on_Jan_27th.2C_2014
13:08:00 <irenab> sadasu: I see your comment now. I think its specific to the plugin/Mech driver.
13:08:12 <sadasu> my concern was that, ML2 mechanism drivers may not be able to support changing pci flavor after port create
13:08:37 <irenab> I think PCI flavor should not be changed, agree with you
13:08:45 <sadasu> yes, I want to discuss if it specific to my case or should it be requirement at update port level?
13:08:57 <irenab> its like VM flavor with PCI alias, no way to change it
13:08:57 <sadasu> same with port config?
13:09:21 <sadasu> yes, I think we should make it clear in the doc also
13:09:40 <irenab> sadasu: OK, will add clarification
13:09:58 <baoli> Sounds good
13:10:14 <sadasu> how about profile_id?
13:10:36 <irenab> sadasu: its specific to your case
13:10:49 <sadasu> if will allow that to be changed, domain xml needs to be rewritten, is that a supported operation in nova?
13:11:03 <baoli> We need to find out
13:11:14 <irenab> sadasu: baoli: are you available after the meeting, to take it offline?
13:11:15 <sadasu> renab: agreed....I need to get clarification on any nova constraints so bringing it up now
13:11:22 <rkukura> which doc are we discussing?
13:11:36 <sadasu> Irena's neutron doc
13:11:41 <baoli> https://docs.google.com/document/d/1RfxfXBNB0mD_kH9SamwqPI8ZM-jg797ky_Fze7SakRc/edit?pli=1
13:11:57 <rkukura> sorry - getting online right at 8:00 EST is difficult due to dropping kids off at school
13:12:28 <baoli> I was a little late too this morning
13:12:32 <sadasu> rkukura: +1 but we were trying to accomodate several time zones
13:13:10 <sadasu> we were trying to accomodate nova guys
13:13:44 <rkukura> not asking to change schedule - just trying to catch up - should have joined the meeting channel before going
13:14:16 <irenab> do we have action item on which port settings can be modified with regards to SR-IOV?
13:14:18 <baoli> #action take a look at nova updating domain xml while the VM is running
13:14:29 <irenab> baoli: +1
13:14:53 <ijw> 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 <sadasu> I have no other questions/comments on the doc at this time
13:15:30 <irenab> sadasu: great
13:15:32 <ijw> 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 <sadasu> ijw: exactly
13:16:15 <baoli> ok. can we proceed with https://wiki.openstack.org/wiki/Meetings/Passthrough#Agenda_on_Jan_27th.2C_2014
13:18:44 <sadasu> I think we had some open action items left over from last Wed's meeting
13:19:12 <irenab> baoli: I agree with the plan presented here
13:19:29 <ijw> So the sriov_group would be the thing we pass Neutron to tell if the physical network attachment?
13:19:44 <irenab> baoli: added 2 comments on the wiki page
13:20:05 <ijw> And I'm not sure how you avoid pci-flavor but you seem to imply it's possible
13:20:35 <baoli> irenab, cann't find the comments. Can you paste it here to discuss
13:20:49 <irenab> just look for irenab
13:21:31 <baoli> got it
13:21:59 <irenab> baoli:no major issues
13:22:08 <baoli> Thanks, irenab
13:22:21 <ijw_> OK, sorry, my connection dropped there and I may have missed a couple of bits
13:22:36 <ijw_> Is there any reason we're passing limited selections to Neutron for the PCI device rather than all its attributes?
13:22:55 <baoli> It would be great if no work is in the neutron client area
13:23:23 <irenab> baoli: need to verifu, but pretty sure it will work as is
13:23:28 <baoli> I need to think about how to use host aggregate for the scheduling issue
13:24:02 <baoli> irenab, I will take a close look at it too, and list possible items if any
13:24:08 <ijw_> baoli: in what way?
13:24:30 <baoli> ijw, can you clarify your question?
13:25:04 <ijw_> Are you talking about John's host aggregate discussions or something else?
13:25:10 <ijw_> I don't think they were related to Neutron.
13:25:25 <baoli> 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 <irenab> ijw: no just the way to filter hosts that should accomodate only SR-IOV vNICs
13:25:43 <baoli> That's what we are talking about
13:26:52 <irenab> admin should define host aggregate with Hosts that shoud serve the SR-IOV using VMs
13:27:14 <ijw> 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 <irenab> when 'nova boot' is called it will specify Host Agggreate
13:28:02 <baoli> how to prevent a regular 'nova boot' from scheduling a vm on a host that supports SRIOV?
13:28:19 <ijw> 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 <baoli> irenab, do you require the host aggregate to be used all the time?
13:28:32 <ijw> Oh, SRIOV only hosts, you mean?
13:28:37 <ijw> Yeah, I would go with that for now
13:29:00 <irenab> baoli: no, just for now if this requured
13:29:16 <irenab> another option, not to run there any vSwitch
13:29:29 <irenab> so port-binding will fail
13:30:00 <irenab> and VM will be booted on othe Host
13:30:10 <baoli> irenab, if we are talking about the short-term goal, sure, we can avoid this requirement
13:30:29 <heyongli> agree with a short term goal
13:30:33 <rkukura> Port binding would fail, but we want to avoid scheduling there so that doesn't happen
13:30:36 <irenab> baoli: currently talking the short term
13:31:18 <heyongli> this scheduler problem does relate to host itself.
13:31:20 <irenab> I guess we are back to neutron-aware-scheduler, but its for Juno, yes?
13:31:44 <baoli> irenab, yes. So we don't want to support coexistence of SRIOV-only and non-SRIOV compute nodes initially
13:32:06 <irenab> I actually think we should, why not?
13:32:23 <rkukura> 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 <ijw_> Sorry, my network hates me today
13:32:56 <irenab> rkukura: I think Host aggregates may be used already now
13:32:57 <baoli> irenab, then we go back to the same issue.
13:33:20 <irenab> baoli: can you please clarify the issue
13:33:32 <ijw_> 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 <irenab> I think the coexistence of OVS + SRIOV is more important
13:34:26 <heyongli> agree, and this request seems does not impact pci scheduler.
13:34:29 <baoli> #issue,coexistence of SRIOV-only and non-SRIOV compute nodes
13:34:56 <ijw_> 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 <irenab> baoli: what issue do you see when coexistence should be supported?
13:35:16 <rkukura> 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 <baoli> ijw, that's right
13:36:04 <baoli> nova boot --flavor 1 --image <imuuid> --nic net-id=net vm
13:36:25 <baoli> if host 1 supports sriov only nic, host 2 supports non-sriov nic,
13:36:44 <baoli> you don't want 'vm' to be running on host 1
13:37:00 <ijw> 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 <ijw> Make sense?
13:37:54 <baoli> ijw, not sure. the filter basically works the same as the existing PCI filter, with some new constraints added
13:38:02 <heyongli> 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 <rkukura> ijw: Sounds like we want nova to never schedule onto an SRIOV aggregate unless that aggregate is explicitly requested, right?
13:38:45 <ijw> 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 <heyongli> rkukura, so the aggregate does has this for now.
13:39:52 <irenab> 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 <ijw> 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 <heyongli> ijw: agree
13:40:57 <irenab> I think the coexistence case is quite important, since same VM may have different NIC types
13:41:13 <ijw> Indeed - so this is really about avoiding SRIOV hosts when you have no SRIOV needs
13:41:37 <irenab> ijw: exactly
13:41:49 <baoli> 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 <heyongli> baoli, cool
13:42:20 <irenab> baoli: fine
13:42:23 <baoli> I'll start the thread after the meeting
13:42:29 <ijw> 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 <irenab> ijw: +1
13:42:56 <baoli> ijw, that sounds fine to me
13:43:25 <baoli> Any more comments to the plan?
13:43:35 <ijw> all good
13:44:14 <irenab> baoli: need to see that all parts have owners
13:44:23 <baoli> irenab, yes.
13:44:28 <ijw> As it stood, I think it was:
13:44:40 <ijw> heyongli: pci_information initially, then pci_flavor_attrs (?)
13:44:42 <heyongli> basiclly i will take all in extra_info blue prints.
13:44:48 <ijw> irenab: Neutorn
13:44:48 <ijw> ijw: scheduler
13:45:14 <ijw> baoli: CLI and API changes
13:45:25 <heyongli> ijw: sure, i take that definitely,
13:45:33 <irenab> ijw: for neutron we have general part for ML2 and NechDriver for Cisco  and Mellanox
13:45:49 <heyongli> and pci flavor, DB, object and API , we had another guy for this
13:45:58 <irenab> I am on general part right now
13:46:08 <baoli> Let's start with nova part
13:46:22 <irenab> baoli: VIF DRiver is yours?
13:46:38 <ijw> I can do that too, up to you - tell me what you need
13:46:39 <baoli> irenab, not a problem.
13:46:50 <ijw> ... but obviously I prefer giving baoli all the work ;)
13:47:26 <irenab> will probably need a way to coordinate, so please be on IRC when available
13:47:35 <ijw> 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 <heyongli> ijw: patch is quickly release, i think.
13:48:07 <ijw> Cool.
13:48:33 <baoli> Yeyongli, so do you agree with the SRIOV items in nova
13:48:37 <heyongli> cause i had most of them alredy, and i re-assmeblem them according bp
13:48:41 <ijw> 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 <heyongli> baoli, sure
13:49:33 <heyongli> baoli, in detail code interface, catch me or yunhong in any time
13:49:43 <irenab> 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 <heyongli> irenab, it's risk
13:50:19 <heyongli> especially nova part
13:50:24 <baoli> heyongli, sure. Especially I need the marker thing we've discussed
13:50:52 <heyongli> baoli: sure, let's talk it in mail thread
13:51:52 <baoli> heyongli, sure
13:52:21 <heyongli> so seems we can back to weekly meeting?
13:52:41 <ijw> 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 <heyongli> and i will on vacation from Tuesday, yunhong will cover me.
13:52:55 <irenab> ijw: agree
13:53:04 <ijw> Sounds like we're on track for that now, mind you, but don't put them up 5 days before ;)
13:53:28 <baoli> So let's make it clear who is doing what.
13:53:28 <heyongli> ijw. i kind of worry the nova bp and nova review process.
13:54:00 <ijw> There's the open question of PCI flavors, I think, versus John's host aggregate suggestion.
13:54:19 <baoli> ijw, also the issue I raised in last IRC meeting
13:54:30 <ijw> heyongli: I think we'll make reasonable process if we have consensus
13:54:33 <ijw> baoli: what was that?
13:54:53 <baoli> ijw, I guess that you didn't take it seriously
13:55:09 <ijw> baoli: I wasn't there on Thursday and haven't checked the minutes
13:55:32 <baoli> ijw, sorry, the issue I raised on Wednesday, I guess
13:56:11 <ijw> remind me?
13:56:44 <irenab> so are we still having meeting on daily basis?
13:56:52 <ijw> passing the attr list back and forth?
13:56:56 <baoli> 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 <ijw> 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 <ijw> You're right, it needs doing, let me spec it up
13:57:56 <baoli> Let's have one tomorrow, and then go back to normal schedule unless something urgent comes up
13:58:04 <heyongli> sure
13:58:17 <irenab> ok
13:58:34 <baoli> I'm still not very clear who's doing what. Let's make it clear tomorrow
13:58:38 <ijw> heyongli: I'll forward that spec to you, it's all tied up with the backend stuff
13:58:58 <ijw> baoli: list is up there ^^^
13:58:58 <irenab> ijw: please send to all
13:59:16 <heyongli> ijw: for me , i think it no suprise, anyway, let's discuss
13:59:37 <baoli> ok, we'll meet again tomorrow?
13:59:51 <heyongli> sure
13:59:55 <baoli> Thanks everyone
13:59:59 <irenab> sure, and have list of items with owners?
14:00:04 <sadasu> yes, we should
14:00:19 <baoli> Sure. Let's start with email today?
14:00:27 <baoli> #endmeeting