Hi Bob and Irena, Thanks for the clarification. Irena, I am not opposed to a SriovMechanismDriverBase/Mixin approach, but I want to first figure out how much common functionality there is. Have you already looked at this?
Thanks, Sandhya On 2/5/14 1:58 AM, "Irena Berezovsky" <[email protected]> wrote: >Please see inline my understanding > >-----Original Message----- >From: Robert Kukura [mailto:[email protected]] >Sent: Tuesday, February 04, 2014 11:57 PM >To: Sandhya Dasu (sadasu); OpenStack Development Mailing List (not for >usage questions); Irena Berezovsky; Robert Li (baoli); Brian Bowen >(brbowen) >Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV >binding of ports > >On 02/04/2014 04:35 PM, Sandhya Dasu (sadasu) wrote: >> Hi, >> I have a couple of questions for ML2 experts regarding support of >> SR-IOV ports. > >I'll try, but I think these questions might be more about how the various >SR-IOV implementations will work than about ML2 itself... > >> 1. The SR-IOV ports would not be managed by ova or linuxbridge L2 >> agents. So, how does a MD for SR-IOV ports bind/unbind its ports to >> the host? Will it just be a db update? > >I think whether or not to use an L2 agent depends on the specific SR-IOV >implementation. Some (Mellanox?) might use an L2 agent, while others >(Cisco?) might put information in binding:vif_details that lets the nova >VIF driver take care of setting up the port without an L2 agent. >[IrenaB] Based on VIF_Type that MD defines, and going forward with other >binding:vif_details attributes, VIFDriver should do the VIF pluging part. >As for required networking configuration is required, it is usually done >either by L2 Agent or external Controller, depends on MD. > >> >> 2. Also, how do we handle the functionality in mech_agent.py, within >> the SR-IOV context? > >My guess is that those SR-IOV MechanismDrivers that use an L2 agent would >inherit the AgentMechanismDriverBase class if it provides useful >functionality, but any MechanismDriver implementation is free to not use >this base class if its not applicable. I'm not sure if an >SriovMechanismDriverBase (or SriovMechanismDriverMixin) class is being >planned, and how that would relate to AgentMechanismDriverBase. > >[IrenaB] Agree with Bob, and as I stated before I think there is a need >for SriovMechanismDriverBase/Mixin that provides all the generic >functionality and helper methods that are common to SRIOV ports. >-Bob > >> >> Thanks, >> Sandhya >> >> From: Sandhya Dasu <[email protected] <mailto:[email protected]>> >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >> <[email protected] >> <mailto:[email protected]>> >> Date: Monday, February 3, 2014 3:14 PM >> To: "OpenStack Development Mailing List (not for usage questions)" >> <[email protected] >> <mailto:[email protected]>>, Irena Berezovsky >> <[email protected] <mailto:[email protected]>>, "Robert Li (baoli)" >> <[email protected] <mailto:[email protected]>>, Robert Kukura >> <[email protected] <mailto:[email protected]>>, "Brian Bowen >> (brbowen)" <[email protected] <mailto:[email protected]>> >> Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV >> extra hr of discussion today >> >> Hi, >> Since, openstack-meeting-alt seems to be in use, baoli and myself >> are moving to openstack-meeting. Hopefully, Bob Kukura & Irena can >> join soon. >> >> Thanks, >> Sandhya >> >> From: Sandhya Dasu <[email protected] <mailto:[email protected]>> >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >> <[email protected] >> <mailto:[email protected]>> >> Date: Monday, February 3, 2014 1:26 PM >> To: Irena Berezovsky <[email protected] >> <mailto:[email protected]>>, "Robert Li (baoli)" <[email protected] >> <mailto:[email protected]>>, Robert Kukura <[email protected] >> <mailto:[email protected]>>, "OpenStack Development Mailing List (not >>for usage questions)" >> <[email protected] >> <mailto:[email protected]>>, "Brian Bowen (brbowen)" >> <[email protected] <mailto:[email protected]>> >> Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV >> extra hr of discussion today >> >> Hi all, >> Both openstack-meeting and openstack-meeting-alt are available >> today. Lets meet at UTC 2000 @ openstack-meeting-alt. >> >> Thanks, >> Sandhya >> >> From: Irena Berezovsky <[email protected] >> <mailto:[email protected]>> >> Date: Monday, February 3, 2014 12:52 AM >> To: Sandhya Dasu <[email protected] <mailto:[email protected]>>, "Robert >> Li (baoli)" <[email protected] <mailto:[email protected]>>, Robert Kukura >> <[email protected] <mailto:[email protected]>>, "OpenStack >> Development Mailing List (not for usage questions)" >> <[email protected] >> <mailto:[email protected]>>, "Brian Bowen (brbowen)" >> <[email protected] <mailto:[email protected]>> >> Subject: RE: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on >> Jan. 30th >> >> Hi Sandhya, >> >> Can you please elaborate how do you suggest to extend the below bp for >> SRIOV Ports managed by different Mechanism Driver? >> >> I am not biased to any specific direction here, just think we need >> common layer for managing SRIOV port at neutron, since there is a >> common pass between nova and neutron. >> >> >> >> BR, >> >> Irena >> >> >> >> >> >> *From:*Sandhya Dasu (sadasu) [mailto:[email protected]] >> *Sent:* Friday, January 31, 2014 6:46 PM >> *To:* Irena Berezovsky; Robert Li (baoli); Robert Kukura; OpenStack >> Development Mailing List (not for usage questions); Brian Bowen >> (brbowen) >> *Subject:* Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV >> on Jan. 30th >> >> >> >> Hi Irena, >> >> I was initially looking >> at >> >>https://blueprints.launchpad.net/neutron/+spec/ml2-typedriver-extra-port- >>info to take care of the extra information required to set up the SR-IOV >>port. >> When the scope of the BP was being decided, we had very little info >> about our own design so I didn't give any feedback about SR-IOV ports. >> But, I feel that this is the direction we should be going. Maybe we >> should target this in Juno. >> >> >> >> Introducing, */SRIOVPortProfileMixin /*would be creating yet another >> way to take care of extra port config. Let me know what you think. >> >> >> >> Thanks, >> >> Sandhya >> >> >> >> *From: *Irena Berezovsky <[email protected] >> <mailto:[email protected]>> >> *Date: *Thursday, January 30, 2014 4:13 PM >> *To: *"Robert Li (baoli)" <[email protected] <mailto:[email protected]>>, >> Robert Kukura <[email protected] <mailto:[email protected]>>, >> Sandhya Dasu <[email protected] <mailto:[email protected]>>, "OpenStack >> Development Mailing List (not for usage questions)" >> <[email protected] >> <mailto:[email protected]>>, "Brian Bowen (brbowen)" >> <[email protected] <mailto:[email protected]>> >> *Subject: *RE: [openstack-dev] [nova][neutron] PCI pass-through SRIOV >> on Jan. 30th >> >> >> >> Robert, >> >> Thank you very much for the summary. >> >> Please, see inline >> >> >> >> *From:*Robert Li (baoli) [mailto:[email protected]] >> *Sent:* Thursday, January 30, 2014 10:45 PM >> *To:* Robert Kukura; Sandhya Dasu (sadasu); Irena Berezovsky; >> OpenStack Development Mailing List (not for usage questions); Brian >> Bowen (brbowen) >> *Subject:* [openstack-dev] [nova][neutron] PCI pass-through SRIOV on >> Jan. 30th >> >> >> >> Hi, >> >> >> >> We made a lot of progress today. We agreed that: >> >> -- vnic_type will be a top level attribute as binding:vnic_type >> >> -- BPs: >> >> * Irena's >> https://blueprints.launchpad.net/neutron/+spec/ml2-request-vnic-type >> for binding:vnic_type >> >> * Bob to submit a BP for binding:profile in ML2. SRIOV input info >> will be encapsulated in binding:profile >> >> * Bob to submit a BP for binding:vif_details in ML2. SRIOV output >> info will be encapsulated in binding:vif_details, which may include >> other information like security parameters. For SRIOV, vlan_id and >> profileid are candidates. >> >> -- new arguments for port-create will be implicit arguments. Future >> release may make them explicit. New argument: --binding:vnic_type >> {virtio, direct, macvtap}. >> >> I think that currently we can make do without the profileid as an >> input parameter from the user. The mechanism driver will return a >> profileid in the vif output. >> >> >> >> Please correct any misstatement in above. >> >> >> >> Issues: >> >> -- do we need a common utils/driver for SRIOV generic parts to be >> used by individual Mechanism drivers that support SRIOV? More details >> on what would be included in this sriov utils/driver? I'm thinking >> that a candidate would be the helper functions to interpret the >> pci_slot, which is proposed as a string. Anything else in your mind? >> >> */[IrenaB] I thought on some SRIOVPortProfileMixin to handle and >> persist SRIOV port related attributes/* >> >> >> >> -- what should mechanism drivers put in binding:vif_details and how >> nova would use this information? as far as I see it from the code, a >> VIF object is created and populated based on information provided by >> neutron (from get network and get port) >> >> >> >> Questions: >> >> -- nova needs to work with both ML2 and non-ML2 plugins. For regular >> plugins, binding:vnic_type will not be set, I guess. Then would it be >> treated as a virtio type? And if a non-ML2 plugin wants to support >> SRIOV, would it need to implement vnic-type, binding:profile, >> binding:vif-details for SRIOV itself? >> >> */[IrenaB] vnic_type will be added as an additional attribute to >> binding extension. For persistency it should be added in >> PortBindingMixin for non ML2. I didn't think to cover it as part of >> ML2 vnic_type bp./* >> >> */For the rest attributes, need to see what Bob plans./* >> >> >> >> -- is a neutron agent making decision based on the binding:vif_type? >> In that case, it makes sense for binding:vnic_type not to be exposed >> to agents. >> >> */[IrenaB] vnic_type is input parameter that will eventually cause >> certain vif_type to be sent to GenericVIFDriver and create network >> interface. Neutron agents periodically scan for attached interfaces. >> For example, OVS agent will look only for OVS interfaces, so if SRIOV >> interface is created, it won't be discovered by OVS agent./* >> >> >> >> Thanks, >> >> Robert >> > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
