14:02:38 <baoli> #startmeeting PCI Passthrough meeting
14:02:39 <openstack> Meeting started Tue Dec 24 14:02:38 2013 UTC and is due to finish in 60 minutes.  The chair is baoli. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:42 <openstack> The meeting name has been set to 'pci_passthrough_meeting'
14:02:51 <baoli> Hi everyone
14:02:56 <irenab> hi
14:03:01 <yongli> hello everyone, could you be on the irc when you are free? that might help we get progress?
14:03:15 <BrianB_> hi
14:03:18 <baoli> @yongli, sure
14:03:18 <irenab> yongli: sure
14:03:31 <yongli> i can grab someone to talk, that's happy
14:04:16 <baoli> I sent an agenda yesterday. Shall we go through them first?
14:04:29 <yongli> yeah
14:04:47 <baoli> #topic auto-discovery
14:05:30 <irenab> baoli: do you want to recap?
14:05:49 <baoli> Yongli, can you explain your concern about "VF doesn't appear in the device tree"?
14:06:14 <yongli> some driver don't put then in any of class
14:06:19 <yongli> them
14:06:44 <yongli> this is depend on driver, we might use pf to identify this
14:06:55 <baoli> @yongli, then how openstack would be able to use them?
14:07:29 <yongli> we get it's class name, do you mean this?
14:08:00 <baoli> @yongli, would libvirt be able to discover them and make them available with hostdev-list?
14:08:25 <irenab> yongli: cannot we assume VF has same class as PF? at least to start with?
14:08:51 <yongli> what's hostdev-list? whit-list?   the class name can be a  property of a device
14:09:10 <yongli> it's reasonable
14:09:41 <baoli> @yongli, a VF can be used to be passed through when it can be seen from libvirt, right?
14:10:12 <yongli> but libvirt driver no this information now, this will took long time to implement in libvirt itself
14:10:43 <baoli> So it means that libvirt has to be able to list all the VFs available under a PF so that VMs can use them, right>
14:10:56 <yongli> i mean the class information(fix me)
14:11:00 <irenab> yongli: but there is libcirt support for network interface type=hostdev
14:11:00 <yongli> yeah, libvirt can do this
14:11:03 <irenab> libvirt
14:12:05 <yongli> irenab, you can specify this, but where we  get the class information from libvirt?
14:12:06 <baoli> So all the VFs are discoverable by libvirt. Since its a PCI device, it belongs to a class if it follows linux standard.
14:13:05 <irenab> yongli: I think that currently there s no way to get class via libvirt, but baoli suggested /sys/net... way
14:13:11 <yongli> we can not ensure all VF in a class name, i might be wrong , but i do not find them in my system, as a alternative we can use PF's class information
14:13:47 <baoli> @yongli, what kind of card are you using?
14:13:59 <baoli> is it a networking card?
14:14:05 <yongli> a NIC
14:14:11 <irenab> yongli: going with PF class is fair enough, I think
14:14:19 <yongli> and a accelerating card
14:14:57 <baoli> So basically, you are saying that you don't know all the VFs under the PF. But you can use the PF to allocate VFs for VMs?
14:15:32 <yongli> irenab, yeah, big problem might be where we coding this, libvirt driver or libvirt itself
14:15:32 <yongli> baoli: no
14:15:49 <baoli> @yongli, I'm lost
14:17:30 <baoli> There are several ways to do so. both lspci and /sys/net can provide this information, to say the least
14:18:41 <baoli> Combining that with libvirt "virsh nodedev-list" would reveal all the PCI passthrough devices belongs to specific linux PCI device classes
14:18:49 <yongli> i mean VF might no class, but libvirt can know all VF under a PF
14:18:49 <yongli> libvirt can do: discovery PF and it's VF,
14:18:52 <yongli> if we want use /sys/class/net thing, where we implement this? libvirt itself or libvirt driver of nova
14:18:52 <yongli> ?
14:19:17 <irenab> yongli: I guess driver
14:19:34 <baoli> @yongli, this can be a pluggable driver under the nova/pci
14:21:28 <baoli> pluggable driver may not be a good name. But something under nova/pci
14:21:32 <yongli> i worry about this is time consume, to push it to libvirt  of nova , this is why i suggest we defer this( we still can trying begin  it any way)
14:22:16 <baoli> @yongli, first, we need to see if it's something necessary and doable, then we can worry about the schedule.
14:22:26 <irenab> baoli: can we try to move on to discuss interaction between nova and neutron to see what we can assume to be required by neutron to maintain?
14:22:28 <yongli> put it to nova/pci might be a little bit  good i think, i worry some core require it to sit in the libvir dirver, then we got problem
14:22:52 <irenab> is John here?
14:23:11 <yongli> on vacation i think
14:23:17 <irenab> we really need core members attention
14:23:30 <yongli> irenab, sure
14:23:30 <baoli> @irenab, sure.  Let's move on.
14:24:02 <irenab> baoli: do you want go to next item on agenda?
14:24:11 <irenab> or nova<->neutron
14:24:25 <yongli> any one is good for me
14:24:31 <yongli> any item
14:24:38 <baoli> @irenab, go ahead with the nova-neutron interraction
14:25:07 <irenab> I want to see what we expect from neutron to maintain
14:25:22 <irenab> I think we need the following:
14:25:27 <baoli> #topic nova-neutron interaction
14:25:56 <irenab> 1. make it possible to request certain type of vnic on neutron port (virtio/sr-iov,..)
14:26:18 <irenab> 2. maintain sr-iov related data on neutron port
14:26:44 <baoli> #agreed
14:26:49 <yongli> irenab: what kind of data about sr-iov?
14:27:09 <irenab> yongli: BDF
14:27:37 <yongli> the BDF allocted ? or BDF you want?
14:27:47 <irenab> yongli: allocated
14:28:04 <irenab> I thinkmthat should be resolved by nova and just communicated to neutron
14:28:10 <irenab> agree?
14:29:03 <irenab> 3. need to expose SR-IOV info for create/update/get port to be available to nova for VIF plug
14:29:50 <irenab> for baoli case there is an add-on for port profile, but its not directly bound to SR-IOV nic
14:29:52 <yongli> that's fine to me if it's allocated data
14:30:07 <yongli> irenab, i don't understand  3
14:30:40 <baoli> @irenab, for BDF, is vendor_id:provider_id:domain:bus:slot.func enought infor?
14:31:06 <irenab> yongli: once nova builds xML for netowrk interface, it gets VIFs information previously retrived from neutron
14:31:39 <irenab> this info should contain all that needed to create correct netowrk interface
14:31:55 <irenab> baoli: think its enough
14:32:12 <yongli> irenab, what kind SR-IOV infomation in your point 3.
14:32:13 <irenab> baoli: did sadusu had some progress with neutron part?
14:32:37 <baoli> @irenab, in that case, it should be part of the port binding information passed in between nova-neutron.
14:32:52 <irenab> yongli: same BDF that was provided for create
14:32:55 <irenab> baoli: agree
14:33:10 <yongli> irenab, got
14:33:11 <baoli> @irenab, on sadasu with neutron, she is not working on that.
14:33:39 <irenab> baoli: I see
14:33:55 <baoli> @irena, I agree on all of the three points.
14:34:07 <irenab> baoli: do you plan to have some neutron support during Icehouse?
14:34:19 <baoli> @irenab, yes
14:34:26 <irenab> baoli: cool
14:34:40 <yongli> i'm ok also.
14:35:05 <irenab> I can try to compose some suggestion for wha tis needed for neutron till next meeting
14:35:32 <irenab> so we can start to close the details
14:35:35 <baoli> @irenab, sure. Also, take a look at the google doc on the neutron part.
14:35:45 <irenab> baoli: sure
14:36:06 <irenab> so I guess we can move to next item, in case you have something more
14:36:11 <irenab> on this
14:36:26 <baoli> I'd like to close on the nova front. Because it's critical for the rest of the work
14:36:35 <yongli> interrupt,  do you guy still again API (vs config)?
14:37:12 <baoli> #topic, PCI group
14:38:26 <irenab> yongli: Ian has strong objection, I guess there is a reason for both
14:38:27 <baoli> On config versus API, let's go through the pro can cons on each of them
14:39:08 <baoli> First, let's discuss the config method
14:40:20 <baoli> it's autonomous, flexible
14:40:40 <baoli> easy to do with provisioning tool
14:40:44 <baoli> agreed?
14:41:12 <irenab> baoli: agree
14:41:13 <yongli> disagree easy, atleast API i not hard
14:41:31 <yongli> s/i/is
14:41:39 <baoli> @yongli, it can be done through provisioning tool, only once
14:42:04 <yongli> auotnomous by deploy?  many deploy tools use API also, right?
14:42:31 <baoli> what are the cons with the config method?
14:42:39 <yongli> for the only once config: this not depend it's config or API, both on time
14:42:50 <yongli> s/ on /one, sorry
14:43:37 <irenab> yongli: API can be gor for monitor, get methods
14:43:45 <irenab> good
14:44:10 <baoli> Irenab, agreed
14:44:42 <baoli> @yongli, the concern is with the pci-group-update method
14:44:46 <yongli> irenab, i'm lost about your point
14:45:11 <baoli> Do you plan to put compute node specific information in the arguments?
14:45:14 <yongli> @baoli, why worry about the update ?
14:45:40 <irenab> yongli: sorry for type, I mean API can be good to read what Host has, not to set
14:45:49 <yongli> baoli, not now, if the pci-flavor define is couple to whitelist
14:46:17 <baoli> @yongli, can you provice the exact command syntac for pci-group-update
14:46:38 <yongli> @baoli, wait a moment
14:47:00 <yongli> nova pci-flavor-create  name 'GetMePowerfulldevice'  description "xxxxx"
14:47:04 <yongli> nova pci-flavor-update UUID  set    'description'='xxxx'   'address'= '0000:01:*.7', 'host'='compute-id'
14:48:17 <irenab> yongli: what will happen as a result of last command?
14:48:18 <baoli> For pci-flavor-update, in order to provision a HOST, it has to issue that command to the controller.
14:48:23 <yongli> i list host here, cause per my understanding this is needed, but John say, it's global, so don't need the host information here
14:48:32 <baoli> how do you plan to decommission a compute node, then
14:49:06 <baoli> Ok, let's say the host argument will be removed
14:49:13 <yongli> baoli: yeah,
14:50:05 <yongli> baoli: i don't see the decomission problem, what is it
14:50:12 <irenab> yongli: I think it makes sense to define the available pci-flavors centrally (or API or Conf), but not patterns per compute
14:50:34 <baoli> the address = '0000:01:*.7', let's say that i want to add a compute node that doesn't meet that criteria, devices on those addresses have different functions
14:51:40 <yongli> baoli: this will be a problem, i agree,
14:52:31 <baoli> In a cloud where all the compute nodes are identical, it's ok. But we shouldn't try to force that in our APIs and implementations
14:52:31 <yongli> John suggest define 2, and expose via aggregate
14:53:05 <irenab> yongli: what do you mean define 2?
14:53:15 <yongli> define another flavor
14:53:35 <baoli> @yongli, without the pci-group-update, would aggregate still work with pci-group?
14:53:50 <irenab> yongli: it does not make sense, from networking perspective they are equal
14:54:35 <yongli> i saw all the argue about this on thread,  we need get approve from John
14:55:05 <irenab> yongli: I guess it will be after the New Year ...
14:55:14 <yongli> John did not decide it yet
14:55:40 <yongli> i'm very ok without the API to modify it, it's equal for me
14:56:23 <baoli> ok, let's close today's meeting with action items
14:56:24 <irenab> yongli: I am also not sure what is about requesting SRIOV nic, I mean --nic or server flavor
14:56:54 <yongli> i think John will accept --nic also
14:57:11 <BrianB_> Is there an issue supporting both API and config
14:57:13 <irenab> yongli: great
14:57:27 <yongli> i'm not sure, i also think the --nic, the nic-flavor is good
14:57:49 <yongli> BrianB_, yeah, what you do if API modiy the config file's content in the DB?
14:58:07 <yongli> and what you should do when reboot?
14:58:43 <yongli> except we store the flavor's definition source
14:58:47 <irenab> yongli:  will this require change to scheduler filter?
14:58:58 <yongli> irenab: minor
14:59:28 <irenab> yongli: good
14:59:35 <yongli> i finished the code for pre review, i hope  you guy to take a look at it, that's would help
14:59:44 <irenab> baoli: we are out of time. What's next?
15:00:01 <baoli> action items
15:00:08 <irenab> yongli: please send the link
15:00:22 <yongli> the code include: group, regular expression support, schuduler, group on demand ...
15:00:44 <yongli> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/pci-extra-info,n,z
15:00:51 <yongli> also try to impment the --nic  style interface
15:01:01 <baoli> @yongli, great that you have the code. I will take a look at it
15:01:02 <yongli> server flavor is support by nature
15:01:03 <irenab> yongli: thanks, will take a look
15:01:48 <baoli> Can we rewrite the google doc with all the different proposals?
15:01:50 <irenab> baoli: I take an action item to drive the neutron story
15:01:50 <yongli> John want to see pre-release code also , i think this good idea, might make some progress
15:02:44 <yongli> baoli: i suggest just describe the interface to nova not the implement design, keep docs identical to blue print is a over work for me
15:02:57 <baoli> #agreed
15:03:59 <baoli> who wants to work on that?
15:05:18 <baoli> Ok, let's close today's meeting, and resume after new year
15:05:34 <baoli> #endmeeting