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