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:sad...@cisco.com]
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 ire...@mellanox.commailto:ire...@mellanox.com
Date: Thursday, January 30, 2014 4:13 PM
To: Robert Li (baoli) ba...@cisco.commailto:ba...@cisco.com, Robert
Kukura rkuk...@redhat.commailto:rkuk...@redhat.com, Sandhya Dasu
sad...@cisco.commailto:sad...@cisco.com, OpenStack Development Mailing
List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org,
Brian Bowen (brbowen) brbo...@cisco.commailto:brbo...@cisco.com
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:ba...@cisco.com]
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
Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th
Hi Irena,
Thanks for the Reply. See inline…
If possible, can we put details on what would be exactly covered by each BP?
--Robert
On 1/30/14 4:13 PM, Irena Berezovsky
ire...@mellanox.commailto:ire...@mellanox.com wrote:
Robert,
Thank you very much for the summary.
Please, see inline
From: Robert Li (baoli) [mailto:ba...@cisco.com]
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
[Robert] This makes sense to me. Would this live in the extension area, or
would it be in the ML2 area? I thought one of the above listed would cover the
persistence of SRIOV attributes. But sounds like we need this BP.
-- 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.
[Robert] Sounds good to me. But again, which BP would cover this?
-- 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.
[Robert] I get the idea. it relies on what are plugged onto the integration
bridge by nova to determine if it needs to take actions.
Thanks,
Robert
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 ire...@mellanox.commailto:ire...@mellanox.com
Date: Thursday, January 30, 2014 4:13 PM
To: Robert Li (baoli) ba...@cisco.commailto:ba...@cisco.com, Robert
Kukura rkuk...@redhat.commailto:rkuk...@redhat.com, Sandhya Dasu
sad...@cisco.commailto:sad...@cisco.com, OpenStack Development Mailing
List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org,
Brian Bowen (brbowen) brbo...@cisco.commailto:brbo...@cisco.com
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:ba...@cisco.com]
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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th
On 01/30/2014 03:44 PM, Robert Li (baoli) wrote:
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
This is https://blueprints.launchpad.net/neutron/+spec/ml2-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.
This is https://blueprints.launchpad.net/neutron/+spec/vif-details.
-- 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.
By vif output here, do you mean binding:vif_details? If so, do we know
how the MD gets the value to return?
Please correct any misstatement in above.
Sounds right to me.
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?
I'd suggest looking at the
neutron.plugins.ml2.drivers.mech_agent.AgentMechanismDriverBase class
that is inherited by the various MDs that use L2 agents. This handles
most of what the MDs need to do, and the derived classes only deal with
details specific to that L2 agent. Maybe a similar
SriovMechanismDriverBase class would make sense.
-- 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)
I think nova should include the entire binding:vif_details attribute in
its VIF object so that the GenericVIFDriver can interpret whatever
key/value pairs are needed (based on the binding:vif_type). We are going
to need to work closely with the nova team to make this so.
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?
Makes sense to me.
-- 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.
I'm not sure I understand what an L2 agent would do with this. As I've
mentioned, I think ML2 will eventually allow the bound MD to add
whatever info it needs to the response returned for the
get_device_details RPC. If the vnic_type is needed in an SRIOV-specific
L2 agent, that should allow the associated driver to supply it.
Thanks,
Robert
-Bob
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th
On 01/31/2014 11:45 AM, Sandhya Dasu (sadasu) wrote:
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.
That BP covers including additional information from the bound network
segment's TypeDriver in the response to the get_device_details RPC. I
believe the bound MechanismDriver should also have the opportunity to
include additional information in that response. Possibly the bound
MechanismDriver is what would decide what information from the bound
segment's TypeDriver is needed by the L2 agent it supports. Anyway, I'm
still hopeful we can get this sorted out and implemented in icehouse,
but I agree its best to not depend on it until juno.
Introducing, SRIOVPortProfileMixin would be creating yet another way to
take care of extra port config. Let me know what you think.
This SRIOVPortProfileMixin has been mentioned a few times now. I'm not
clear on what this class is intended to be mixed into. Is this something
that would be mixed into any plugin that supports SRIOV?
If so, I'd prefer not to use such a mixin class in ML2, where we've so
far been avoiding the need to add any specific support for SRIOV to the
plugin itself. Instead we've been trying to define generic features in
ML2 that allow SRIOV to be packaged as an optional feature enabled by
configuring a MechanismDriver that supports it. This approach is a prime
example of the modular goal of Modular Layer 2.
-Bob
Thanks,
Sandhya
From: Irena Berezovsky ire...@mellanox.com mailto:ire...@mellanox.com
Date: Thursday, January 30, 2014 4:13 PM
To: Robert Li (baoli) ba...@cisco.com mailto:ba...@cisco.com,
Robert Kukura rkuk...@redhat.com mailto:rkuk...@redhat.com, Sandhya
Dasu sad...@cisco.com mailto:sad...@cisco.com, OpenStack
Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
mailto:openstack-dev@lists.openstack.org, Brian Bowen (brbowen)
brbo...@cisco.com mailto:brbo...@cisco.com
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:ba...@cisco.com]
*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
[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?
-- 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?
-- 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.
Thanks,
Robert
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
