13:00:28 <baoli> #startmeeting PCI passthrough 13:00:29 <openstack> Meeting started Wed May 7 13:00:28 2014 UTC and is due to finish in 60 minutes. The chair is baoli. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:33 <beagles> o/ 13:00:33 <openstack> The meeting name has been set to 'pci_passthrough' 13:00:39 <baoli> hi 13:01:15 <irenab> hi 13:01:48 <johnthetubaguy> hi 13:02:01 <baoli> John, welcome 13:02:31 <irenab> Hi John! 13:02:35 * johnthetubaguy waves 13:02:54 <baoli> What do you guys want to go over for this last meeting before the summit? 13:03:39 <johnthetubaguy> is everything ready for summit session? etherpad all prepared? 13:03:45 <irenab> I think we need to be sure that all topics we want to discuss are on the etherpad 13:04:13 <johnthetubaguy> you got the link? 13:04:13 <baoli> irenab did a good job on the etherpad 13:04:33 <baoli> https://etherpad.openstack.org/p/pci_passthrough_cross_project 13:04:36 <irenab> Do we want to set a time for meeting before the session? Monday morning or other day during key notes? 13:05:08 <sadasu> baoli: did you startmeeting? 13:05:33 <baoli> sadasu, yes 13:05:44 <irenab> I would like to discuss the scope for the nova-spec we are currently blocked with -2 13:05:59 <sadasu> topic hasn't changed for me 13:06:43 <irenab> sadasu: there was some automatic zuul announcment that messed the topic 13:06:56 <sadasu> ok...got it 13:07:00 <johnthetubaguy> so on the etherpad… did you want to give a description of the problems you are trying to solve? 13:07:03 <johnthetubaguy> and agree on those 13:07:10 <sadasu> back to nova pec 13:07:11 <johnthetubaguy> it seems to dive into the details quite a lot 13:08:14 <irenab> shall we start with naive case were all VM vnics are SRIOV is VM flavor defines so? 13:08:33 <johnthetubaguy> well, just all nics are SRIOV would do 13:08:33 <irenab> ^if defines so 13:08:41 <sadasu> also, I think it has been proven that the choice of nic_type sriov and macvtap isn't working 13:08:50 <johnthetubaguy> then look at flow between nova and neutron 13:09:31 <sadasu> the nova spec comments clearly asks for a level of indirection where we use diff terms to identify vnic_types 13:09:43 <irenab> sadasu: currentl with pre created neutron port, I can create VMs with both SR-IOV and OVS based vNICs, which is quite cool 13:09:56 <johnthetubaguy> yeah, but I am not sure we agree the basics yet 13:10:39 <irenab> john: this is works without changing nova apis 13:11:10 <baoli> John, what basics in your mind that we should discuss on? 13:11:29 <irenab> I think to make some progress, we can srtart with the basic case that per VM all vnics can be either SR-IOV or non SR-IOV 13:11:52 <johnthetubaguy> baoli: I am thinking just the basic SRIOV use case of all nics are SRIOV 13:12:05 <johnthetubaguy> nova and neutron interaction specifying whats going on, etc 13:12:23 <johnthetubaguy> how nova picks the correct host with the request network the user wants, etc 13:13:05 <baoli> john, in that case, all we need to do is to remove the user CLI change, and add a config to say all nics are SRIOV or not 13:13:31 <baoli> all the other changes would remain the same. 13:13:32 <irenab> john: agree with baoli, seems that setting it on VM flavor layer can work here 13:14:02 <baoli> irenab, I think john is talking all sriov across a cloud 13:14:09 <johnthetubaguy> yeah 13:14:13 <johnthetubaguy> across the whole cloud 13:14:18 <johnthetubaguy> then lets look at the next options 13:14:28 <johnthetubaguy> we already have to pick the correct network, as requested by the user, etc 13:14:41 <irenab> I do not lkie this case so much, too limiting. Why not do it per VM? 13:15:12 <baoli> john, like I responded in the comments, even picking up the right network is not specific to SR-IOV 13:15:20 <beagles> the idea.. correct me if I am wrong... is that provides a simplified case in which we can work out the details of nova/neutron coordination, implement the vif driver level details etc, and focus on the user-facing details as an independent aspect 13:15:40 <sadasu> irenab: agree with you...but lets use this use case to completely figure out the part where Nova picks the correct physical network... 13:15:45 <johnthetubaguy> baoli: OK, but usually all networks are available everywhere, if you use virtual networking 13:15:58 <johnthetubaguy> baoli: SRIOV is very much more restrictive 13:16:24 <johnthetubaguy> baoli: we can scope that out if we want, assume all networks are everywhere, but that feels wrong 13:16:39 <sadasu> johnthetubaguy: yes because of its dependency on physical network connectivity 13:17:09 <baoli> john, so can we assume that all the networks are avaialble on all the hosts? 13:17:19 <irenab> john: except for limited number of VFs, I do not see major limitations compared to virtual networking. For virtual networking, Host should be connected to appropriate physicalnetwork 13:17:37 <sadasu> johnthe tubaguy: then we are essentially describing the virtual port case 13:18:00 <irenab> with ML2 plugin, port won't be bound if host is not connected to physical network 13:18:07 <johnthetubaguy> well its the limited number of VFs I was worried about, its a consumable port 13:18:29 <johnthetubaguy> yeah, we have to co to the correct host though, I thought, but anyway, clearly this is not a useful discussion 13:18:37 <johnthetubaguy> lets move to something else 13:19:10 <irenab> I feel we are stuck till we agree on basic case to cover 13:19:22 <johnthetubaguy> yeah 13:19:43 <johnthetubaguy> I am thinking the simple case should be all NICs are SRIOV 13:19:44 <irenab> shall we start with HPC like cloud => all vnics are SR-IOV? 13:19:51 <sadasu> I think we are all willing to start with a admin specified setting for vnic_type that applies to the entire cloud 13:20:05 <irenab> but still, I think it is not real world case 13:20:18 <sadasu> irenab: agreed...starting point 13:21:26 <johnthetubaguy> so I added 4 use cases on the bottom of the etherpad 13:21:33 <johnthetubaguy> do they look "correct"? 13:24:00 <irenab> john: looks ok for me 13:24:01 <johnthetubaguy> ? 13:24:28 <sadasu> didn't quite get #3 13:24:31 <johnthetubaguy> wondering if I missed a case 13:25:10 <johnthetubaguy> sadasu: is that better? 13:25:26 <irenab> for #1, if the only mechanism driver in ML2 plugin is SR-IOV, this will be resolved by neutron 13:25:32 <baoli> John, regarding case 2, how do you define slow versue fast? 13:25:42 <sadasu> johnthetubaguy: what about the case where a VM wants a virtual and Sr-iov port for the same VM 13:25:51 <sadasu> ...diff from the bonded case 13:26:06 <irenab> sadasu: +1 13:26:26 <johnthetubaguy> sorry, 2 was not clear 13:26:39 <johnthetubaguy> that is the SRIOV and virtual on the same server 13:26:51 <irenab> john: probaly #3 is not required, it maybe temporary solution till api is converged 13:27:08 <johnthetubaguy> irenab: I agree, but I wanted to raise it, so we reject it 13:27:54 <sadasu> about #3, I think we could potentially end up with lots of flavors...knobs are physical network, # sriov ports, type of sriov ports, # of virtual port 13:28:05 <sadasu> might be confusing to the user 13:28:16 <johnthetubaguy> sadasu: agreed, its stupid, but we need to discuss it to exclude it 13:28:28 <sadasu> ok....got it :-) 13:28:38 <johnthetubaguy> it seems like the "obvious" way to do this, till you think about the details 13:28:38 <baoli> john, for case 2, if it's one to one mapping, why use another level of indirection? 13:29:07 <johnthetubaguy> baoli: because the user shouldn't know about the implementation 13:29:09 <irenab> so the main question is what details we want tenant to be exposed to? 13:29:15 <johnthetubaguy> and you might want three types 13:29:30 <baoli> then why not choose the right term in the first place? 13:29:56 <johnthetubaguy> baoli: I don't get your point? 13:30:10 <johnthetubaguy> what term would you prefer? 13:30:29 <baoli> if it's one to one mapping: slow - virtual, fast - sriov, 13:30:50 <irenab> john: maybe you can sync us with your vision for volume type like approach? 13:31:11 <johnthetubaguy> basically, the user gets to choose between some set of labels for the different types 13:31:18 <johnthetubaguy> the admin gets to choose what that really means 13:31:39 <johnthetubaguy> so it could be, virtual, 1Gb SRIOV, 10Gb SRIOV 13:31:41 <baoli> john, in our case, the user wants to choose sriov versus non-sriov ports 13:32:07 <johnthetubaguy> baoli: OK, but the user being so "savvy" shouldn't be the assumed case I think 13:32:21 <baoli> john, like I responded in the spec's comments, 1G versus 10G is not specific to SR-IOV 13:32:28 <irenab> Do you suggest admin creates nic types defined with some lable exposed to tenant? 13:32:31 <johnthetubaguy> we spoke before about many other users for that indirection, it seems a shame not to add it 13:32:39 <johnthetubaguy> irenab: basically, yes 13:33:07 <irenab> other details that should be used for scheduling is associated by admin but not exposed to the tenant? 13:33:28 <johnthetubaguy> right 13:33:33 <baoli> I think that we should consider what we need to solve specifically for SR-IOV networking, not to be confused with some general issues (or functionationlities) 13:33:53 <johnthetubaguy> so you could have two different vendors of things, all under and single label, if we wanted to do that, without changing the end user API 13:34:14 <johnthetubaguy> baoli: this API will live for ever once we add it, we have to get that right 13:34:34 <baoli> john, agreed on that. 13:34:56 <baoli> john, does the admin care about choosing vendors? 13:35:20 <baoli> John, or even normal user cares about choosing vendors when using sr-iov technology 13:35:38 <irenab> baoli: it may be reasonable if different vendors can be part of the same deployment 13:35:43 <baoli> do we talk about vendors when using non-sriov networking 13:35:58 <johnthetubaguy> well, its more the ability not to choose that worries me, but I think we are crossed wires here 13:36:03 <johnthetubaguy> lets roll back a little bit 13:36:24 <johnthetubaguy> do we agree with the use cases as they are now? (ignoring how we implement them) 13:36:32 <johnthetubaguy> they seem valid 13:37:21 <johnthetubaguy> ah, wait, I remember 13:37:31 <johnthetubaguy> its the macvtap vs direct vs virtual 13:37:39 <johnthetubaguy> that is an admin choice I feel 13:37:45 <johnthetubaguy> macvtap vs direct 13:38:00 <johnthetubaguy> the user wants "slow" vs "fast", in their view of the world 13:38:12 <johnthetubaguy> unless they happen to know how hypervisors, work 13:38:28 <johnthetubaguy> in which case you just change the labels to "SRIOV" vs "Virtual" 13:39:16 <baoli> john, do we assume that all three types can coexist in the same cloud? 13:39:17 <irenab> john: so to start with #2, nic type with single key holding vnic_type will be enough? 13:39:44 <irenab> baoli: I think they may coexist in the same VM 13:40:13 <johnthetubaguy> yeah, same VM 13:40:33 <johnthetubaguy> irenab: yeah, I think vnic_type just being a string passed to Nova, might do the trick 13:40:49 <johnthetubaguy> irenab: ideally needs to be scoped, etc, but yeah, thats all 13:41:09 <irenab> case #1 is actually equivalent to monolitic neutron SR-IOV plugin case (pre ML2 plugin) 13:42:36 <irenab> john: just to understand what you have in mind, do you cuggest new model object "nic type" or vnic_type as parameter of --nic? 13:42:44 <irenab> ^suggest 13:42:46 <johnthetubaguy> irenab: right, or ML2 configured with a single type 13:43:08 <johnthetubaguy> irenab: I don't know, I think vnic_type param would do the trick 13:43:20 <johnthetubaguy> irenab: I worry more about expressing what the user wants at this point 13:43:36 <johnthetubaguy> irenab: and making sure we capture the "problem" we want to solve 13:44:50 <baoli> john, if we want to add other information such as vendor, port bandwidth, etc, another level of indirection may make sense. However, same thing would apply to non-sriov ports as well. 13:45:17 <johnthetubaguy> baoli: yes, it probably does, this is just one use of it 13:45:51 <baoli> john, if we agree with that, then we should have a common solution for both sriov and non-sriov ports for those 13:46:00 <irenab> seems to me that currently we have an option to request vnic_type via neutron port passed to nova boot command. 13:46:04 <johnthetubaguy> yeah, probably, I don't totally get the other use cases 13:46:10 <baoli> then what's unique to sriov is the number of VFs. 13:46:51 <baoli> And if we don't care about mis-scheuling, the number doesn't matter 13:47:04 <irenab> for proper way to request vnic_type via nova api, we probably need 'nic type' 13:47:08 <baoli> I mean the limited number of VFs doesn't matter 13:49:10 <johnthetubaguy> OK... 13:49:16 <johnthetubaguy> so I added another use case 13:49:21 <johnthetubaguy> as #3 13:49:37 <johnthetubaguy> I think that relates quite a lot to the ML2 case 13:49:44 <johnthetubaguy> how does it look? 13:53:01 <irenab> I am not comfortable with admin decides per network what vnic user gets, it may serve as default if tenant does not specify 13:53:44 <baoli> I actually don't quite understand 3 & 4 13:54:22 <johnthetubaguy> so #3, as it is now 13:54:32 <johnthetubaguy> user picks there networks as they do today 13:55:06 <johnthetubaguy> but admin gets to pick that public network is SRIOV, vs all private networks are implemented using OVS, say 13:55:18 <baoli> john, that sounds good to me 13:55:31 <sadasu> we have 5 mins, can we quickly decided when to meet during the summit? 13:55:33 <sadasu> Monday? 13:55:35 <beagles> johnthetubaguy, just spitballing, but you are conceptualizing a progression of functionality (ie. a way we can incrementally implement things) or a use case that will be supported "forever"? 13:55:35 <johnthetubaguy> #4, user picks between medium.SRIOVnet vs medium.regularNET 13:55:57 <beagles> s/you are/are you/ 13:56:04 <irenab> Monday works for me 13:56:19 <johnthetubaguy> I fear I would be tied up all Monday 13:56:55 <irenab> Tue during keynotes? 13:57:02 <sadasu> johnthetubaguy: what would be a good time for you? 13:57:08 <sadasu> and beagles? 13:57:40 <johnthetubaguy> sadasu: there probably isn't one I am afraid 13:58:11 <sadasu> lunch time? 13:58:23 <johnthetubaguy> beagles: i was hoping to agree something of the end goal, so we can see how to step towards that 13:58:30 <johnthetubaguy> beagles: so the hope is for both 13:58:36 <beagles> johnthetubaguy, cool 13:58:42 <irenab> it would be good to set expectations from the summit session: scope and work items assigment, right? 13:59:03 <johnthetubaguy> irenab: agreeing the problems we want to solve would be good, so scope yes 13:59:22 <johnthetubaguy> I really want to see things move forward in Juno, this is the chance really 13:59:53 <irenab> sadasu: lunch time will work for me 13:59:53 <sadasu> johnthetubaguy: +1 13:59:58 <baoli> john, I think that we all share the same goal 14:00:15 <sadasu> I was really hoping to have some whiteboard/unconference type session 14:00:26 <irenab> sadasu: +1 14:00:36 <irenab> let's try to converge on meeting time before the session over ml? 14:01:25 <sadasu> agreed. 14:01:40 <baoli> sounds good to me 14:01:41 <johnthetubaguy> looking forward to the session, anyways, will be good to hash this out in person 14:01:54 <sadasu> +1 14:02:19 <baoli> I guess that we'll see each other in the summit then 14:02:29 <irenab> sadasu: can you please send out an email? 14:02:58 <sadasu> ok...I am afraid it will just be the usual culprits (3 of us) responding :-) 14:03:27 <irenab> thanks all! I I need to go, see you in the summit 14:03:41 <baoli> thanks everyone 14:03:45 <baoli> #endmeeting