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