13:01:22 #startmeeting PCI passthrough 13:01:22 Meeting started Tue Jan 27 13:01:22 2015 UTC and is due to finish in 60 minutes. The chair is baoli. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:01:26 The meeting name has been set to 'pci_passthrough' 13:01:35 Hi there 13:01:40 hi 13:01:48 hi 13:03:07 hi 13:03:08 hi 13:04:35 https://wiki.openstack.org/wiki/Meetings/Passthrough#Agenda_on_Jan._27th.2C_2015 13:05:01 beagles: I moved yours to the Open discussion 13:05:27 baoli, cool 13:06:34 #topic bugs 13:07:47 actually if we have nothing to bring up in the normal agenda, we can go straight into open discussions. 13:08:48 * pczesno shows up late 13:08:53 quiet bunch this morning :) 13:10:53 moshili: will look at your new upload for https://review.openstack.org/#/c/145035/ 13:11:12 ok 13:11:34 so... does anybody have any info or background on the patch I noted: https://review.openstack.org/#/c/149605/2 ? 13:11:35 also I am updated the suspend bug there was merge conflict 13:12:18 it didn't have a spec and I'm afraid I wouldn't have noticed it at all if someone didn't add me to the review (moshele?) 13:13:06 moshele: will +1 it 13:14:03 I wasn't aware for this patch I added my self because we are interested in something like this 13:14:37 beagles: thanks for bringing it up to our attention 13:14:50 beagales: I thought your spec also cover it, no ? 13:15:29 the bp was introduced by Adrian Hoban (AFAICT) but there is no actual spec to go with it. It seems to be the same sort of ground but introduces the concept of device group to the pci list etc. so probably covers some specific use cases 13:15:52 https://blueprints.launchpad.net/nova/+spec/libvirt-sriov-nic-bonding was registered by Przemyslaw 13:16:14 baoli, ah right so it was 13:16:49 beagles: yes, but we heaven't started working on that yet 13:17:35 pczesno, ack. 13:17:51 beagles: nikolay is not working with us, he just used an existing bp 13:18:03 pczesno, ahhh okay 13:18:11 thanks for clarifying that 13:19:27 I am actually interested in the overall story about the sriov nic bonding. 13:21:12 baoli: our inital plan was to implement the scenario where bonding is done by the host, but in the end didn't have enough bandwitdh to do that 13:21:41 baoli: beagles is working on the bonding in the guest scenario 13:22:00 pczesno: can you describe how that can be achieved? 13:22:55 baoli: it was for macvtap only , libvirt can do the bonding 13:23:17 pczesno: I see 13:25:17 But for direct sriov, Let's say a VM is provided with two SR-IOV interfaces, each of them is from a different physical port. How is the VM informed that the two sriov interfaces should be bonded together? How is layers provisioned in the VM, etc? 13:25:38 s/layers/layer3 13:27:50 baoli: i guess vm assumes that it should bond the ports, there are things i don't uderstand about bonding in the vm 13:28:08 beagles: what's your plan? 13:28:28 pczesno, your understanding is consistent with mine... basically making it so the ports are consistent with the intent of bonding in the guest 13:28:53 I have not heard anyone state requirements that guestside bonding be handled by openstack 13:29:09 I'd presume that would be more inline with bonding outside of the guest 13:29:53 beagles: what if VM requests 4 sriov ports , how will it know which 2 to bond? 13:32:16 pczesno, outside of the scope I was aiming at really. 13:32:25 beagles: ah ok 13:33:00 regarding the bonding on the guest maybe it can be done using cloud init? 13:33:31 pczesno, we went scrounging for solid user requirements so we could build use cases and we didn't get solid info. During that process I saw a room for an incremental improvement. 13:34:46 cloud init may work provided the interface layout does not chage for the lifetime of the vm. how would attch work in this case? 13:35:25 also how dhcp/l3 would work in the case? 13:36:39 build a specialized config drive? 13:37:03 baoli, basically wouldn't .. the vm would have to handle the bonding however it saw fit 13:37:03 that would convey all the information required for the vm to configure the bonded interface? 13:37:19 baoli, yeah or similar 13:38:12 beagles: a better understanding of the mechanism for guest bonding would help in the long run. 13:38:15 baoli, basically the orchestration once it had the ports would be left up to something else. 13:39:58 baoli, sure... my perspective is somewhat influenced by fielding requests for address-less ports (which we don't have). It seems there are folks who just want the ports and for OpenStack to just stay out of the way afterwards. 13:40:31 nova supported this for some time and people were happy with that, but when it was pointed out that neutron couldn't do it .. it was fixed 13:40:42 in that nova lost its ability to do that :) 13:41:06 anyways.... 13:41:49 I would think that people who wanted hands off bonding would prefer that it were handled outside of the vm and then all of that crap is dealt with 13:42:23 beagles: so basically nova/neutron should support that a vm launched with l2 ports? 13:43:37 baoli, more or less.. basically a permutation of "flat" networking. 13:45:11 beagles: there seems to be some discussion in the community on that ^^ 13:45:33 its a degenerate case because somewhere between folsom and havana, addressing in flat networking became more "regular"... you could still do it, but at some point openstack required an address pool and allocated addresses for it.. even if they were never used - or something. 13:46:07 beagles: any pointer on that discussion? 13:46:52 baoli, yeah.. l2 ports have been a "asked for" for some time and while there have been blueprints that are somewhat related (addressless interfaces ) they weren't exactly "it" - because ports still would have addresses. 13:47:11 baoli, not right at hand but I can look 13:48:31 beagles: ok 13:52:23 unless people have something to bring up, I guess that we are done for today. 13:52:52 baoli, I'll add links to the agenda for next week's open discussion on this stuff, okay? 13:52:53 i would like to ask for review on : https://review.openstack.org/#/c/140290/ 13:53:05 * beagles continues searching 13:53:11 beagles: that sounds great! 13:53:51 pczesno: will do sometime this week 13:54:01 baoli: thanks 13:55:12 * beagles adds himself to review 13:56:41 Thanks everyone. See you next time. 13:56:57 #endmeeting