13:00:29 <baoli> #startmeeting PCI Passthrough
13:00:30 <openstack> Meeting started Thu Jan 30 13:00:29 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:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:33 <openstack> The meeting name has been set to 'pci_passthrough'
13:00:56 <baoli> Hi
13:01:07 <BrianB_> Hi
13:01:09 <irenab> hi
13:01:17 <rkukura> hi
13:01:49 <baoli> #topic neutron BPs for SRIOV
13:02:11 <irenab> lets refine the neutron part first?
13:02:12 <baoli> #topic vnic_type
13:02:25 <baoli> irenab, go ahead
13:02:54 <irenab> so for vnic_type we have a bp, and discussion on mailing list where to define it
13:03:17 <irenab> I think it fit the port binding space
13:03:34 <baoli> I second it.
13:03:53 <rkukura> lets resolve top-level vs. binding:profile 1st, then if former, decide which extension
13:04:30 <baoli> Given it's functionality, it fits well as binding:vnic_type
13:05:08 <irenab> baoli: I also think so, it just require change to CLI/API
13:05:24 <rkukura> Is there consensus it needs to be top-level,  and is this due to needing use access?
13:05:30 <rkukura> s/use/user/
13:05:41 <irenab> rkukura: do not think so
13:05:51 <rkukura> irenab: No consensus?
13:06:16 <irenab> No for user access, as I said in the mail, he user will set something much more abstract
13:06:41 <irenab> 'high performance ...' NIC
13:06:56 <rkukura> I'd be happiest if this we admin-only (in binding:profile) and the user passed something in --nic to nova that resulted in nova setting up binding:profile as admin.
13:07:19 <rkukura> s/this we/this was/
13:07:21 <irenab> rkukura: exactly what I have in mind
13:07:46 <irenab> may it be admin or network owner?
13:07:47 <rkukura> I apologize that I'm not even trying to keep up with the nova side of these discussions
13:08:17 <irenab> rkukura: I think we should be able to decouple nova and neutron
13:08:23 <rkukura> Normally, network owners are normal users, and don't know/see anything internal to the deployment
13:08:57 <irenab> rkukura: so they won't create neutron port?
13:09:15 <rkukura> Plus, we need to make sure its works for normal user whether they are the owner of the network, or someone else owns the network and sets --shared True
13:09:32 <baoli> if we call it nic_type (instead of vnic_type): virtio/direct/macvtap? would it be less confusing?
13:10:20 <irenab> baoli: do you think user should be able to set it?
13:11:00 <baoli> The question is that should the user be allowed to choose a virtio port versus sriov port?
13:11:11 <rkukura> Do we have a plan in place on the nova side for nova code to set things in binding:profile, or is the idea that users do this manually, and later nova automates it?
13:11:34 <irenab> yes, or it should be admin choice
13:12:00 <sadasu> we were designing for "nova code to set things in binding:profile"
13:12:03 <baoli> rkukura, we did. But due to the discussions we had so far, we changed the course, and decided to work on the neutron port-create first
13:12:18 <sadasu> and then what baoli said happened
13:12:45 <rkukura> baoli: That's what I thought, but we need to know whether we can assume the neutron port-create/port-update is done by nova as admin
13:12:54 <irenab> rkukura: for vnic_type it will be user choice translated by nova to vnic_type and set on neutron port
13:13:19 <baoli> that's right, irenab
13:13:37 <rkukura> irenab: Sounds good, just want to make sure the nova code will make icehouse
13:14:09 <irenab> for icehouse, we do not need nova for vnic_type, we set it on neutron port via port-create
13:14:10 <baoli> rkukura, we are not going to change the nova code/CLI in the initial release
13:14:32 <irenab> and then use --nic port_id = xxx for novaboot
13:14:33 <rkukura> irenab: Normal users are not admin
13:15:13 <rkukura> Does this same thing apply to other details like PCI slot, ...?
13:15:14 <baoli> rkukura, so normal users can not choose a virtio port versus a sriov port?
13:15:47 <rkukura> the VNIC that the user's VM sees is really a nova concept, not a neutron concept.
13:15:54 <irenab> PCI slot is not user or admin choice directly, nova allocates it
13:16:27 <baoli> rkukura, nova boot can be used by normal users
13:16:40 <rkukura> irenab: So in icehouse, will nova store pci_slot in binding:profile (as admin)?
13:17:29 <irenab> depends on baoli's work :-)
13:17:56 <rkukura> baoli: I'm not arguing that normal users should not be able to specify the VNIC type, just that they should do this through nova API so that nova does all the right stuff, including what's needed on the neutron port
13:18:21 <irenab> rkukura: I think we all agree
13:18:24 <baoli> rkukura, following the existing work flow in nova, binding:profile will be set and neutron port-update is called
13:18:57 <rkukura> If we can count on having some nova code in icehouse that creates/updates the neuton port with binding:profile as admin, then I think we just stick with using binding:profile for all this.
13:19:50 <rkukura> So my issue with users needing to directly set vnic-type on the neutron port was misguided, right? I was hoping for that answer!
13:20:19 <baoli> rkukura, if a normal user can choose the nic_type from nova boot, why it can't do so in the neutron port-create command?
13:20:38 <irenab> rkukura: initialy we for icehouse we start with setting vnc_type on neutron port and then run nova-boot
13:21:23 <rkukura> irenab: Does that same thing apply to the other items (pci slot, ...) that we want to put in binding:profile?
13:21:36 <irenab> rkukura: only vnic_type
13:21:47 <rkukura> So who sets the others?
13:21:56 <irenab> rkukura: nova
13:22:21 <rkukura> So if nova sets the others, why can't it also set vnic_type?
13:23:02 <rkukura> Is the issue that this would require extending the nova API somehow, and we won't get that in icehouse?
13:23:08 <irenab> rkukura: to make long story short, currently lack of agreement and time to implement
13:23:19 <irenab> rkukura: correct
13:23:27 <baoli> rkukura, to use sriov, we need to do this initially: nova boot --flavor m1.large --image <i-uuid> --nic port-id=<port-uuid>
13:23:42 <baoli> so we have to create a sriov port first
13:24:18 <rkukura> Ok, so normal users need to be able to set vnic_type, so best way forward seems to be to make it top-level
13:25:02 <baoli> Cool, so we'll proceed with that?
13:25:13 <rkukura> Then the only question is whether its in the portbindings extension or a different extension
13:25:17 <irenab> rkukura: I think that normal user will get some abstract definition of nic flavors that precreated by admin, and this will imply vnic_type
13:25:46 <rkukura> irenab: For icehouse, or later?
13:25:58 <irenab> rkukura: later
13:26:09 <rkukura> And where does this "abstract definition" live? In nova eventually?
13:26:19 <irenab> Controller
13:26:26 <rkukura> ?
13:26:33 <irenab> like VM Flavors
13:26:40 <rkukura> Oh, nova controller?
13:26:50 <rkukura> Make sense I think
13:27:22 <baoli> ok, back to rkukura's question on the extension
13:27:26 <irenab> I think the port binding seems the right place to land this
13:27:38 <rkukura> So eventually users won't need to deal with binding:vnic_type directly, so hiding it in portbindings extension is fine with me
13:27:55 <irenab> rkukura: Cool
13:28:43 <baoli> ok, so the conclusion is that user can now specify vnic_type and it will be stored as binding:vmic_type
13:28:44 <irenab> so top-level or part of profile on binding, actually depends on how do you plan to deal with profile as part of generic support for ML2
13:29:41 <irenab> since vnic_type should be checked and stored not on Mech Driver level but on the level on top of it
13:29:49 <rkukura> I think baoli is correct because normal users needing access to vnic_type cannot easily be done within binding:profile
13:30:10 <irenab> so top-lvel on binding extension?
13:30:29 <baoli> agree
13:30:32 <rkukura> I think irenab's BP should cover making the ml2 plugin persist binding:vnic_type
13:30:46 <irenab> rkukura: agree.
13:30:50 <baoli> agree
13:30:51 <rkukura> with default of virtio
13:31:00 <irenab> its exactly the code change I shared with you few days
13:31:23 <rkukura> and all binding-capable MechanismDrivers should check the value when trying to bind, and act appropriately
13:31:42 <irenab> so, if we are OK with it, I can complete it and push next week
13:31:53 <rkukura> Sounds good to me!
13:32:14 <rkukura> I'll submit the BP to implement binding:profile in ML2 today, and also push next week
13:32:21 <baoli> One question, where vmci_type is persisted?
13:32:26 <irenab> rkukura: great!
13:32:47 <baoli> s/vmci_type/vnic_type
13:32:49 <rkukura> If vmci_type is in bindng:profile, the ml2 plugin will persist it with my BP
13:33:14 <rkukura> I think binding:vnic type would be persisted by ml2 plugin in its port binding table
13:33:15 <irenab> so the only left on neutron is if we add common utils/driver for SRIOV generic parts to be used by Cisco/Mellanox Mech. Drivers
13:33:45 <irenab> rkukura: exactly what I had in mind
13:33:48 <rkukura> There's also the binding:vif_details output parameter I'm working with Nachi on, right?
13:35:21 <sadasu> should vnic_type be part of the vif_details?
13:35:34 <baoli> One more question, would ovs agent be able to see this binding:vmic_type?
13:35:39 <irenab> sadasu: not, it will be reflected in vif_type
13:36:07 <irenab> baoli: agent should not see it
13:36:14 <rkukura> sadasu: My understanding is that binding:vnic_type is an input param, while binding:vif_details is output
13:36:28 <baoli> irenab, we talked about running multiple agents in the same time, right?
13:36:40 <sadasu> who does the translation from binding_vnic_type to vif_type in vif_details, generic ML2 plugin or specific mech drivers?
13:37:07 <irenab> baoli: we can take it offline, I 'll explain how it is resolved in case we have more on agenda
13:37:16 <sadasu> rkukura: but vif_type in vif_details depends on input vnic_type
13:37:21 <rkukura> baoli: There is a separate effort to let the bound MD control what gets returned to the agent in the get_device_details RPC
13:37:22 <irenab> sadasu: I think Mech. Driver
13:37:33 <baoli> irenab, sure.
13:37:57 <rkukura> sadasu: Yes, the binding:vif_type attribute is output by the bound MD
13:38:15 <sadasu> ok...
13:38:41 <baoli> for sriov, do we need anything from binding:vif_details?
13:39:02 <irenab> rkukura: for PCI details sent via profile, should it be pushed back via vif_details?
13:39:21 <rkukura> Isn't this where nova's GenericVIFDriver might get the VLAN to tag the PF with?
13:39:24 <sadasu> I don't think we need to send the pci address info back via vif_details
13:39:57 <rkukura> irenab: binding:profile is input to neutron, binding:vif_details is output from neutron
13:40:12 <irenab> sadasu: it should be available to VIFDriver
13:40:38 <baoli> So what would be inside this binding:vif_details for SRIOV?
13:40:58 <baoli> would get_port() return binding:profile?
13:41:10 <sadasu> irenab: agreed. But, since it is already an inout via binding_profile, why do we send it back out ?
13:41:10 <rkukura> In my view each binding:vif_type value will determine what nova's GenericVIFDriver looks for in binding:vif_details. The GenericVIFDriver and the MD that bindings need to agree on how this works.
13:42:31 <irenab> for SRIOV MD we have some common part and part that specific for solution. Cisco has profile_id, right?
13:42:56 <rkukura> The dictionary returned by port-create, port-update, and port-show will contain binding:vnic_type for all users, and for admins will contain binding:vif_type, binding:profile, and binding:vif_details
13:42:57 <baoli> rkukura, I think that it can be done that way. It's just that we need to figure out how much it will impact the existing code, and what would be inside binding:vif_details for SRIOV
13:43:05 <sadasu> rkukura: Ideally, we would need the pci address details and "profile_id" (here profile is a libvirt term) to be part of vif_details
13:43:52 <irenab> we may want vlan_id to be there too, since libvirt can set it
13:44:23 <sadasu> irenab: for me its part of profile_id...but yes...depending on MD functionality
13:44:59 <sadasu> but the only part I am not clear about is, should pci address be part of vif_details...
13:45:08 <baoli> Ok, sure so we'll set vif_details to includes things like profileid and/or vlan_id
13:45:08 <irenab> sadasu: agree, but any SRIOV Mech Driver require pci address to be present
13:45:16 <rkukura> Seems we need to be working on a concrete proposal regarding what the MDs put in binding:vif_details and how nova's GenericVIFDriver uses binding:vif_type and binding:vif_details
13:45:41 <sadasu> we know GebericVIFDriver needs it
13:45:54 <irenab> rkukura: do you say the binding:profile won't be propagated to VIFDriver?
13:46:05 <sadasu> will be able to get it directly from Nova, or should it be part of vif_details?
13:46:26 <baoli> rkukura, it's something called VIF dictionary
13:46:33 <sadasu> I don't know implementation of GenericVIFDriver well enough to answer that question myself
13:46:47 <baoli> nova invokes neutron get_port which will return everything
13:47:04 <rkukura> I think GenericVIFDriver has admin access to the port, so it should see binding:vif_type, binding:vif_details, and binding:profile
13:47:14 <irenab> baoli: not everything is propagated to VIFDriver
13:47:38 <baoli> irenab, the VIF object
13:48:00 <irenab> GenericVIFDriver does not call into neutron, it receives what is on VIF object, but not all attributes of port present there
13:48:01 <rkukura> Would probably make sense for nova to propagate all the portbindings attributes to the VIF driver
13:48:10 <rkukura> including the new ones
13:48:42 <irenab> rkukura: is there a work on nova to support your neutron bp?
13:48:49 <baoli> We can take a look at the area
13:49:49 <baoli> 10 more minutes. I'd like to talk about the neutron port-create syntax
13:49:56 <rkukura> We need to look at Nachi's nova patch for binding:vif_security, which I've proposed to rename binding:vif_details, and see if its getting propagated to the VIF driver
13:50:39 <irenab> and if we need info from profile, need to see that it is availabe to VIF Driver too
13:50:43 <baoli> irenab, rkukura, how would it look like?
13:51:27 <irenab> baoli: to icehouse we need vnic_type and profile_if for port-create, right?
13:51:36 <rkukura> I think "neutron port-create --binding:vnic_type sriov ..." would work
13:51:38 <baoli> irenab, right
13:51:55 <irenab> so vnic_type is like rkukura said
13:51:56 <baoli> how about the profileid?
13:52:22 <rkukura> Isn't profile_id a key in binding:profile?
13:52:23 <irenab> and profileid in via --binding:profile type=dict profileid=xxx
13:52:35 <rkukura> But only admins can set binding:profile
13:53:50 <baoli> before that, a question is should we make them explicit arguments, rather than unknown arguments? doing a neutron port-create help should display those arguments, right?
13:54:41 <irenab> baoli: sounds like Juno feature....
13:54:45 <rkukura> baoli: I think that is a general question that applies equally to other extensions
13:54:55 <sadasu> I think it is fine for now to have --binding:profile type=dict profileid=xxx set only by admin users
13:55:30 <baoli> ok, we can postpone that to juno
13:55:34 <rkukura> Is the profile_id something that the nova code in icehouse could infer from the flavor and set on binding:profile?
13:55:49 <baoli> sadasu, then the port can only be created by an admin?
13:56:09 <sadasu> rkukura: no
13:56:37 <irenab> great, so having vnic_type and binding:profile bp, do we need bp for common SRIOV on neutron side?
13:56:38 <rkukura> I'm not clear on where a normal user would get values for profile_id?
13:56:43 <sadasu> baoli: for non admin users a profile_is can be created with the vlian_id borrowed from the network that the port would be attached to
13:57:01 <rkukura> Normal users do not know about VLANs
13:57:08 <irenab> sadasu: so it won't be set on port-create?
13:57:29 <sadasu> yes, it won't be set during port create for non-admin userrs
13:57:38 <rkukura> What is the purpose of this profile_id?
13:57:47 <irenab> we have 3 mins left?
13:58:19 <baoli> I think that we have to take it offline. I'll send out some minutes.
13:58:20 <sadasu> rkukura: profile_id would point to a set of config that can be applied to the port
13:58:22 <irenab> I still not sure on the syntax for PCI slot info exchange
13:58:38 <sadasu> like qos, acls etc
13:59:02 <irenab> having further discussion on Mon?
13:59:21 <baoli> That sounds good
13:59:23 <rkukura> IF the profile_id is needed by the GenericVIFDriver, if the bound MD could figure out what it should be and put it in binding:vif_details
13:59:43 <irenab> I'll send an email to the group once push the change for vnic_type. rkukura: can you approve it?
13:59:49 <sadasu> yes, yes
14:00:12 <rkukura> irenab: Are you going to update the BP to match current agreement?
14:00:19 <sadasu> rkukura: yes. but will have to think about it some more
14:00:20 <irenab> rkukura: shure
14:00:38 <irenab> will try to make it today, most late on Sunday
14:00:48 <sadasu> irenab: thanks
14:00:52 <rkukura> irenab: Let me know when the BP is ready to approve and I'll take care of it
14:01:04 <irenab> rkukura: thanks
14:01:19 <baoli> I'll send out some minutes, and the questions we had during this meeting
14:01:25 <baoli> #endmeeting