19:03:14 <sadasu> #startmeeting PCI passthrough
19:03:15 <openstack> Meeting started Mon Nov 25 19:03:14 2013 UTC and is due to finish in 60 minutes.  The chair is sadasu. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:03:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:03:19 <openstack> The meeting name has been set to 'pci_passthrough'
19:03:30 <sadasu> #chair baoli
19:03:31 <openstack> Current chairs: baoli sadasu
19:03:41 <irenab> hi
19:03:43 <baoli> hi everyone, welcome to the meeting
19:04:19 <baoli> now that we have a google doc:https://docs.google.com/document/d/1EMwDg9J8zOxzvTnQJ9HwZdiotaVstFWKIuKrPse6JOs/edit?usp=sharing
19:04:35 <sadasu> #topic design google doc
19:04:42 <baoli> can we go through the following?1: Any questions with current nova-passthrough  2: define pci assignable list on compute nodes:             -- associate a device with a 'group'             -- define pci-devfilter             -- device 'feature' auto-discovery             -- pci alias no longer defined on controller  3: scheduling            -- based on 'group'            -- pci requester            -- lci passthrough onl
19:05:34 <baoli> first of all, any questions with current nova-passthrough implementation?
19:06:15 <irenab> good summary in doc, no question from me
19:08:37 <baoli> thanks, irenab. Looks like that we are all on the same page with the current nova-passthrough
19:11:16 <sadasu> regarding what is currently being proposed, appears everyone wants pci-alias
19:11:23 <sadasu> to be pci-group
19:11:35 <sadasu> is that correct?
19:11:42 <baoli> let's move on to the pci assignable list on the compute node
19:12:05 <baoli> yes, pci-groug seems to be the term to go
19:12:11 <baoli> sorry , pci-group
19:12:25 <irenab> I am confused about terms that used for compute and controller
19:12:48 <irenab> we use pci_alias for Controller and pci-group for compute?
19:13:10 <baoli> compute node runs nova-compute, and controler runs nova-scheduler/nova-api
19:14:01 <baoli> we are suggesting that PCI alias is no longer defined on the controller
19:14:37 <irenab> @baoli: no longer defined at all?
19:15:20 <irenab> pci-group will be used instead?
19:15:33 <baoli> yes
19:15:58 <baoli> an assignable list per compute node: <pci-devfilter, pci-group>
19:16:18 <baoli> pci-group has cloud significance
19:17:02 <irenab> @baoli: just to be sure, its up to admin to manage properly per each compute node?
19:18:04 <baoli> pci-group (the name, and it's underlying implementation) is defined cloud wise, mapping from devices per compute node is defined by the assignable list.
19:20:29 <irenab> @baoli: so pci-group will be used for scheduling purposes, while pci-devfilter will be used for getting the list of suitable devices on compute?
19:21:56 <baoli> That sounds about right to me. pci-group is used for both scheduling and actual allocation on the compute node that is to run the instance. It's also used by the feature to map to the physical network in the case of neutron
19:22:59 <irenab> @baoli: can you please define what you mean by feature?
19:23:24 <irenab> is it something like device-type in current implementation?
19:24:33 <baoli> I can not find a right term for it. But yes, it is similar to the device-type. On the other hand, it means neutron (for network), and possbile cinder (for storage), for example
19:26:20 <irenab> @baoli: so there is a predefined list of 'features' as you stated.
19:27:17 <baoli> That's the current thinking if device 'feature' auto-discovery is possible. It's possible for network devices since they are all mapped to ethernet interfaces on a linux host
19:28:13 <irenab> I think it will be correct to say they are mapped to network interfaces, but not mandatory to ethernet.
19:29:06 <irenab> we have  Infiniband interfaces if NIC connected to IB physical network
19:29:31 <baoli> with mellanox, you mentioned infiniband type of interface. how are they represented in the linux device hierarchy?
19:29:50 <sadasu> irenab: yes, network interfaces and not a specific type of network interface
19:30:25 <irenab> @baoli: I'll put an example on the google doc tomorrow once have access to the machine
19:31:04 <itzikb> @baoli: You mean under /sys/class/net ?
19:31:18 <baoli> #itzikb, yes
19:31:39 <itzikb> @baoli: ib0,ib1 etc ..
19:32:12 <irenab> @baili: with link to actual device like the ethernet if
19:33:21 <baoli> That sounds ok to me because following the symbolic link leads to an pci device and it's within the class 'net'
19:33:36 <irenab> @baoli: correct
19:34:22 <itzikb> @baoli: So the thinking is to go over /sys/class/net in the network 'feature' ?
19:35:30 <baoli> So if libvirt does it, we can use it as yl has commented on the doc. otherwise, I don't know why we can't as long as 'sys/class/net' is a portable implementation
19:36:36 <itzikb> I think libvirt has it - but probably someone can correct me if I'm wrong
19:37:01 <irenab> #baoli: I think both ways should work as long as there is no assumption for specific (Ethernet) network type
19:37:45 <baoli> #itzikb, I didn't find it from the version of libvirt I have. Maybe the lastest libvirt version support that. Regardless, it's possible to figure out the 'class' of a pci device
19:38:13 <baoli> And subsequently use that device for the feature
19:39:39 <irenab> my feeling that community will favor libvirt, but since here we have more than one way to solve, may continue to other item?
19:40:20 <baoli> cool
19:40:42 <baoli> let's discuss pci-devfilter
19:41:36 <baoli> does the name/term sound right to you guys?
19:42:16 <irenab> #baoli: seems fine
19:43:45 <irenab> I think we miss here yongli who had some concerns
19:44:35 <baoli> #irenab, i'm hoping to have a meeting time that he can join
19:45:19 <baoli> Any questions on scheduling?
19:45:52 <sadasu> before that, I think there were concerns about the pci-devfilter format
19:46:21 <irenab> @baoli: can we discuss a bit the request part prior to scheduling?
19:46:29 <baoli> Sure
19:47:25 <sadasu> the goal here is not having the admin to keep entering repetitive fields
19:48:01 <baoli> #sadasu, agreed
19:48:22 <baoli> you can use * or range for each field, and the later parts can be missing
19:48:51 <sadasu> I did not understand, yongli's concern here or even if he has a concern
19:49:15 <sadasu> Ian does not seem to like the format
19:49:55 <baoli> #sadasu, it's just an option. it's open for better ideas
19:50:08 <irenab> #sadasu: Does he have some suggestion?
19:50:25 <sadasu> baoli: agreed. I am just trying to understand the concerns so we can make it better
19:51:18 <irenab> @baoli: can you please explain the way you see admin request for VM with PCI device as vNIC on net1 on physical network=phynet?
19:51:47 <sadasu> @irenab: not sure.
19:52:41 <irenab> @baoli: I mean define any extra-spec on flavor, neutron-port is precreated, etc.
19:52:53 <baoli> @irenab, sure. Assuming it's using VLAN
19:53:28 <baoli> when you create a neutron network, it's assigned a vlan and thus mapped to the physical net, agreed?
19:53:47 <irenab> @baoili: does not matter. I mean what managment operations admin does
19:54:24 <irenab> he created network on phynet and it was allocated with VLAN.
19:54:52 <irenab> Then he creates port with vnic_type SRIOV?
19:55:35 <baoli> --nic net-id=<neutron net associated with physical net>, vnic-type=sriov
19:56:10 <baoli> --nic net-id= <neutron net associated with phynet>, vnic-type=sriov, pci-group=net1
19:56:30 <irenab> @baoli: great. That's all? Or he should also define extra-spec for some flavor?
19:56:37 <baoli> no
19:57:10 <irenab> @baoli: meaning, that's all?
19:57:32 <baoli> yes, no flavor is needed
19:57:45 <baoli> I mean no flavor is needed for networking purpose
19:57:51 <irenab> @baoli: great, thanks.
19:58:16 <baoli> #irenab, would it work for mellanox?
19:59:21 <irenab> @baoli: for what we have discussed till now, seems very generic and will work.
19:59:53 <baoli> I think that our time is up shortly. #itzikb, please let me know how to retrieve device 'class' or 'type' from libvirt if you find out.
20:00:04 <baoli> #irenab, are you able to edit the google doc?
20:00:04 <irenab> @baoli: for the rest described in doc regarding libvirt and neutron, we need to elaborate more
20:00:38 <baoli> @irenab, I will try, or if you can edit, go ahead to edit it with what you think would clarify
20:01:18 <sadasu> #endmeeting