13:04:25 <heyongli> #startmeeting pci_passthrough
13:04:26 <openstack> Meeting started Tue Apr 22 13:04:25 2014 UTC and is due to finish in 60 minutes.  The chair is heyongli. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:04:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:04:29 <openstack> The meeting name has been set to 'pci_passthrough'
13:04:31 <heyongli> hi
13:04:56 <baoli> Hi
13:05:03 <baoli> Sorry that I'm late
13:05:06 <sadasu> hello
13:06:04 <heyongli> sriov spec is in good shape review i think, there are some comments need address, i will update tomorrow.
13:06:17 <irenab> heyongli: thank you for working on it
13:06:22 <russellb> have a link to the spec?
13:06:37 <heyongli> https://review.openstack.org/#/c/86606/
13:06:42 <heyongli> #link https://review.openstack.org/#/c/86606/
13:07:04 <irenab> heyongli: I wanted to ak if you need help from my side to update it
13:07:35 <heyongli> irenab, that long case should be re write
13:07:52 <russellb> no implementors listed on the spec yet
13:07:57 <heyongli> 1. Admin user identifies PCI devices categories. Each category fits
13:07:57 <heyongli> 53	     certain criterias that matches list of equivalent PCI devices.
13:07:57 <heyongli> 54	     Per each compute node, administrator defines list of PCI devices
13:07:57 <heyongli> 55	     available for allocation for each PCI device category.
13:07:57 <heyongli> 56	     Every virtual network is defined on top of certain physical network.
13:07:57 <heyongli> 57	     Admin settings should assure that there is a correlation between
13:07:59 <heyongli> 58	     available PCI devices and device connectivity to the physical network.
13:08:01 <heyongli> 59	     i.e, a SRIOV ready NIC on a host connect to a switch port which provide
13:08:03 <russellb> anyone signed up to help write the code?  i'm interested in helping.
13:08:03 <heyongli> 60	     the vlan physical netowrk, named 'valnphy1'.
13:08:05 <heyongli> 61	     admin should can connect this SRIOV NIC with the physical netowrk
13:08:19 <heyongli> russellb, yeah, john want see use cases first
13:08:28 <heyongli> code is almost ready now
13:08:43 <heyongli> at least for a prototype
13:08:56 <russellb> orly
13:09:12 <russellb> cool
13:09:20 <heyongli> #link https://review.openstack.org/#/q/status:abandoned+project:openstack/nova+branch:master+topic:bp/pci-extra-info,n,z
13:09:35 <irenab> heyongli: I'll take a look on this.
13:09:44 <heyongli> this is for pci common enhancement
13:09:51 <heyongli> sriov part is done by baoli
13:10:37 <irenab> I think we still did not completely reach agreement on tenant apis
13:11:29 <baoli> russellb: we have a lot of stuff over here https://wiki.openstack.org/wiki/Meetings/Passthrough
13:11:30 <irenab> and also admin work flow to setup all parts (aggregates, flavors,...)
13:11:35 <heyongli> irenab, yeah, even we can not get that ready i think the sriov work still can make progress by partition the work
13:12:15 <russellb> baoli: thanks
13:12:17 <heyongli> i prefer split the flaovr to another bp, and put it on top of the dependcy tree
13:12:34 <irenab> I think the best is to put alternatives in the nova-spec we have
13:13:10 <heyongli> alternatives design? also fine to me.
13:13:15 <irenab> heyongli: I think its bettert to have one bp covering SS-IOV nova parts, and it can be submitted via several patches
13:13:58 <heyongli> yeah, the 	specs/juno/pci-passthrough-sriov.rst should at least cover :
13:14:08 <heyongli> 1) nova boot --nic thing
13:14:24 <heyongli> 2) module interface between sriov to common pci passthrough
13:14:29 <heyongli> 3) vif part of code
13:14:47 <baoli> last week, we discussed whether or not the user should be exposed with vendor_id, product_id, and use them for device selection. we haven't reached anything yet.
13:15:12 <irenab> baoli: by user you mean tenant?
13:15:20 <baoli> irenab, yes
13:15:31 <heyongli> baoli, we need that, if sriov don't need it , common pci passthrough need it
13:16:16 <heyongli> and some coner case of image also need the vendor information
13:16:21 <irenab> for SR-IOV passthrough guest should have vendor drivers, so some level of understanding should be there
13:17:08 <baoli> I have looked at the existing filters within the scheduler. Seems like that they are pretty useful in covering those requirements
13:17:36 <baoli> The question is whether or not they should be used as part of the stats keys
13:17:48 <irenab> is there an agreement for nova boot --nic  with vnic-type? Or we should look into some NIC flavors?
13:18:13 <baoli> irenab, I'm pretty happy with the vnic-type
13:18:15 <heyongli> even if  SR-IOV don't need that too much,  the GPU pass-through will need that , cause some tenant want gpu and a compute engine,  in this case, the vendor is almost everything
13:18:46 <heyongli> pci stats need the vendor info come from common pci pass through
13:19:06 <baoli> heyongli, you are saying in the gpu case, a user wants a pci device from a particular vendor
13:19:47 <heyongli> yeah, cause gpu engine had it's private machine code, like x86, arm's different
13:19:56 <irenab> baoli: We should make via tenant friendly apis. I just think we may get reject on putting --vnic-type on nova boot command
13:20:39 <baoli> irenab, that's why we want to hear from the cores about their opionions
13:20:47 <baoli> So far, we have discussed them over and over
13:21:13 <baoli> And now it's time to come to some kind of aggreements
13:21:13 <heyongli> to push forward this, we need a alternative for --nic
13:21:49 <baoli> Well, we need to know what the objections are
13:21:56 <irenab> baoli: so let's see if there are rejecs via nova-spec
13:22:09 <irenab> Do we have it there?
13:22:12 <baoli> We can't discuss this over and over without making any progress
13:22:30 <irenab> I am still trying to close the gap after the vacation :-)
13:23:11 <irenab> so for now lets progress with --vnic-type.
13:23:44 <heyongli> to discuss --vnic, the nova spec need a section doc this
13:24:39 <baoli> one tag versus multiple tags, or the selection criteria.
13:24:39 <baoli> user interface
13:24:41 <baoli> as far as I'm concerned, we are stuck at tow things:
13:25:05 <baoli> those are the two things that we are stuck at
13:25:16 <heyongli> i thinks we agree on multi tags solution
13:25:34 <baoli> heyongli, the difference is whether or not you need multiple keys for the stats keys
13:25:59 <irenab> let's try to close the UI (tenant flow) first in the nova-spec. Once use cases and apis are agreed, the implementation will be less challenging, I think
13:26:04 <heyongli> why multi tag don't need multi key?
13:26:20 <heyongli> irenab, i don't thinks so
13:26:34 <heyongli> api is kind of stand alone here
13:27:11 <heyongli> well decoupled, it's a db version of alias anyway, for both flavor or aggregate
13:27:22 <baoli> we have stats based filter (only PCI filter as far as I know) and property based filters (the rest)
13:28:01 <heyongli> what is property based ? stats just a summary of pci device's property
13:29:13 <baoli> heyongli, if you look at the filters such as compute_capability_filter, aggregate filter, image filter, etc, they use meta-data, and there is no counts of resources invovled
13:29:55 <heyongli> how about vcpu and memory?
13:30:21 <baoli> Refer to the latter part of this doc:https://docs.google.com/document/d/1zgMaXqrCnad01-jQH7Mkmf6amlghw9RMScGLBrKslmw/edit?pli=1
13:30:40 <heyongli> pci is another kind of resources, have many property than cpu and memory
13:36:21 <irenab> lets try to identify what is missing in order to get this bp approved
13:37:16 <irenab> 1. need to cover the proposed change chapter
13:37:24 <heyongli> irenab, i think it's lack of a unify agreement and so can not preset it to community
13:37:40 <heyongli> before this, how write the change chapter?
13:38:03 <irenab> maybe put the alternatives there
13:38:34 <heyongli> agree to put something to alternatives
13:38:44 <baoli> First, would we agree on --vnic-type?
13:39:08 <baoli> if not, what is the alternative?
13:39:24 <irenab> baoli: I am fine with it, but we may expect some objections...
13:39:43 <heyongli> i'm fine, alternative could be integrate it to falvor in some way
13:39:50 <baoli> irenab, well, let's hear about those objections first
13:40:00 <irenab> baloi: agree
13:40:45 <baoli> We should put that in the BP if that's the position we want to take
13:41:15 <irenab> baoli: do you have few moments to update the spec with details you put on the google doc? If not, I can do it.
13:41:54 <irenab> I think the alternative is to make some nic flavor that admin creates and tenant consumes
13:41:56 <baoli> irenab, i will try to update the doc
13:42:13 <heyongli> nova spec we prefer?
13:42:32 <irenab> heyongli: The same nova-spec we started
13:42:43 <heyongli> yeah
13:42:46 <irenab> baoli: If need my help, just ping on IRC
13:42:54 <baoli> irenab, sure.
13:43:12 <baoli> irenab, we have to be clear on what a nic flavor is
13:43:42 <irenab> baoli: let's wait for comments on --vnic-type.
13:44:31 <baoli> irenab, for --vnic-type, it's very clear what it is. But nic flavor, I'd like to see what exactly it is, then we can put it in the doc as an alternative
13:45:10 <baoli> I think we have the common goal of providing a simple interface to meet the admin/user's requirements
13:45:19 <irenab> baoli: I am saying that before inventing some new model objects and apis, let's go with --vnic-type
13:45:52 <baoli> In the same time, take into account what's out of there already.
13:45:56 <baoli> irenab, sure.
13:46:04 <irenab> I am ok with vnic-type, just remember we had John concerns about it
13:47:01 <baoli> irenab, earlier on, we have something else such as profile_id in the picture.
13:47:32 <irenab> baoli: yes, for  QBH case
13:47:47 <irenab> how are you going to deal with it?
13:47:54 <baoli> That's when John talked about something about nic flavor
13:48:24 <irenab> baoli: so going forward, there is no need to propagate it via nova boot command?
13:48:39 <irenab> we just need the vnic_type?
13:49:40 <baoli> Irenab, there are other efforts going on in that front. So we should concern ourself on SR-IOV only
13:49:43 <heyongli> just wonder , why vnic type can not sit in the neutron part? fix me
13:49:48 <sadasu> irenab: yes, we don't need the profile_id to be specified at the nova boot command
13:50:30 <baoli> heyongli, nova boot requires a port from a network
13:50:45 <irenab> sadasu, baoli: good. So the only parameter we need is vnic_type.
13:50:50 <heyongli> then, put the nic type to port of network does not work?
13:51:02 <sadasu> irenab: correct
13:51:16 <baoli> heyongli, I think that we'
13:51:43 <irenab> heyongli: it works, and even already upstream. But the problem is that it required user to work via apis
13:52:03 <irenab> firts create neutron port and then run nova boot
13:52:37 <baoli> Heyongli, sorry. If you look at the nova boot command syntax on --nic, it has three options now: net-id=<>,fixed_ip=<>,port_id=<>. User should either provide net-id or port-id
13:53:03 <irenab> we need to extend nova boot and also add support to GUI to get vnic_type
13:53:52 <heyongli> still confuse, but net id seems lack of a type filed
13:54:20 <baoli> if the user provides a net-id, then the user should be provided an option on whether or not a sr-iov port is desired
13:54:41 <irenab> heyongli: here we have baoli's patch to add vnic-type to nova boot with net-id
13:55:35 <heyongli> irenab, i know , it's got some rejection, so net-id can not perfer a sriov or other type? but seems odd also
13:56:49 <irenab> heyongli: net_id means "I want VM to connect to this virtual network", I think its not to add to specify the properties for such connectivity
13:56:58 <heyongli> in another way, for net id does it possible to choose nic type in another way? like a policy or something?
13:57:23 <heyongli> neutron then can control that without botering the nova
13:57:37 <heyongli> bothering
13:57:58 <irenab> for my understanding, nova just propagates vnic_type to neutron
13:58:31 <baoli> heyongli, we envisioned that for a virtual net, both sr-iov ports and regular ports can be attached to it.
13:58:33 <heyongli> then it's possible choose the type only in the neturon , like a list of wish list
13:59:19 <heyongli> for net id: sriov, virtio means sriov first? does it work?
13:59:31 <beagles> (sorry, arrived late and have been lurking)
13:59:42 <sadasu> heyongli: when the vm is being instantiated, the tenant should be able to decide to use a sr-iov port
13:59:54 <beagles> doesn't vnic_type play a part in scheduling and possibly part of matching image capabilities
14:00:18 <irenab> beagles: currently  not
14:00:19 <sadasu> so assoiating it with a network in advance doesn't make sense
14:00:35 <beagles> irenab, but it should, right?
14:00:49 <sadasu> beagles: yes, but we haven't gotten to that part yet today
14:01:07 <heyongli> --nic does has it's value, for a specific vm , a sriov might be mandatory for tenant
14:01:15 <sadasu> irenab: that is where we are headed even if it is not like that today
14:01:37 <irenab> sadasu: agree
14:01:51 <beagles> k cool
14:02:34 <irenab> actually we have vnic_type and physicla_network tag on available PCI devices, and this will be part of scheduling decision
14:02:39 <heyongli> sadasu, assoiating it with network, it is the list not force to some vnic type
14:03:08 <irenab> baoli: do you use vnic_type to create pci_request?
14:03:55 <heyongli> time is up
14:04:11 <heyongli> #endmeeting