Hi Irena,

With your reply, and after taking a close look at the code, I think that I 
understand it now.

Regarding the cli change:

  neutron port-create –binding:profile type=dict vnic_type=direct

following the neutron net-create —provider:physical_network as an example, 
--binding:* can be treated as unknown arguments. And they are opaquely 
transmitted to the neutron plugin for processing. I have always wondered why 
net-create help doesn't display the —provider:* arguments, and sometimes have 
to google the syntax. After taking look at the code, I think I kind of know 
what's going on out of there.  I'd like to know why it's done that way. But I 
think that it will work for —binding:* in the neutron port-create commands.

now regarding binding:profile for SR-IOV, from your google doc, it will have 
the following properties:
           pci_slot in the format of vendor_id:product_id:domain:bus:slot.fn.
           pci_flavor: will be a PCI flavor name when the API is available and 
it's desirable for neutron to use it. For now, it will be a physical network 
           profileid: for 802.1qbh/802.1br
           vnic-type: it's still debatable whether or not this property belongs 
here. I kind of second you on making it binding:vnic-type.

They all seem to be non plugin or MD specific. Of course, a MD that supports 
802.1br would enforce profileid. But in terms of persisting them, I don't feel 
like they should be done in the plugin. On the other hand, the examples you 
gave me do show that these plugins are responsible for storing plugin-specific 
binding:profile in the DB. And in the case of —provider:* for neutron network, 
it's the individual plugins that persist it, and duplicate the code. Therefore, 
we may not have options other than following the existing examples.


On 1/29/14 12:17 PM, "Irena Berezovsky" 
<ire...@mellanox.com<mailto:ire...@mellanox.com>> wrote:

Hi Robert,
Please see inline, I’ll try to post my understanding.

From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Wednesday, January 29, 2014 6:03 PM
To: Irena Berezovsky; rkuk...@redhat.com<mailto:rkuk...@redhat.com>; Sandhya 
Dasu (sadasu); OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th

Hi Irena,

I'm now even more confused. I must have missed something. See inline….


On 1/29/14 10:19 AM, "Irena Berezovsky" 
<ire...@mellanox.com<mailto:ire...@mellanox.com>> wrote:

Hi Robert,
I think that I can go with Bob’s suggestion, but think it makes sense to cover 
the vnic_type and PCI-passthru via two separate patches. Adding vnic_type will 
probably impose changes to existing Mech. Drivers while PCI-passthru is about 
introducing some pieces for new SRIOV supporting Mech. Drivers.

More comments inline


From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Wednesday, January 29, 2014 4:47 PM
To: Irena Berezovsky; rkuk...@redhat.com<mailto:rkuk...@redhat.com>; Sandhya 
Dasu (sadasu); OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th

Hi folks,

I'd like to do a recap on today's meeting, and if possible we should continue 
the discussion in this thread so that we can be more productive in tomorrow's 

Bob suggests that we have these BPs:
One generic covering implementing binding:profile in ML2, and one specific to 
PCI-passthru, defining the vnic-type (wherever it goes) and any keys for 

Irena suggests that we have three BPs:
1. generic ML2 support for binding:profile (corresponding to Bob's covering 
implementing binding:profile in ML2 ?)
2. add vnic_type support for binding Mech Drivers in ML2 plugin
3. support PCI slot via profile (corresponding to Bob's any keys for 
binding:profile ?)

Both proposals sound similar, so it's great that we are converging. I think 
that it's important that we put more details in each BP on what's exactly 
covered by it. One question I have is about where binding:profile will be 
implemented. I see that portbinding is defined/implemented under its extension 
and neutron.db. So when both of you guys are saying that implementing 
binding:profile in ML2, I'm kind of confused. Please let me know what I'm 
missing here. My understanding is that non-ML2 plugin can use it as well.
[IrenaB] Basically you  are right. Currently ML2 does not inherit the DB Mixin 
for port binding. So it supports the port binding extension, but uses its own 
DB table to store relevant attributes. Making it work for ML2 means not adding 
this support to PortBindingMixin.

[ROBERT] does that mean binding:profile for PCI can't be used by non-ml2 plugin?
[IrenaB] binding:profile is can be used by any plugin that supports binding 
extension. To persist the binding:profile (in the DB), plugin should add DB 
table for this . The PortBindingMixin does not persist the binding:profile for 

Another issue that came up during the meeting is about whether or not vnic-type 
should be part of the top level binding or part of binding:profile. In other 
words, should it be defined as binding:vnic-type or binding:profile:vnic-type.
[IrenaB] As long as existing binding capable Mech Drivers will take vnic_type 
into its consideration, I guess doing it via binding:profile will introduce 
less changes all over (CLI, API). But I am not sure this reason is strong 
enough to choose this direction
We also need one or two BPs to cover the change in the neutron 
port-create/port-show CLI/API.
[IrenaB] binding:profile is already supported, so it probably depends on 
direction with vnic_type

[ROBERT] Can you let me know where in the code binding:profile is supported? in 
portbindings_db.py, the PortBindingPort model doesn't have a column for 
binding:profile. So I guess that I must have missed it.
[IrenaB] For existing examples for supporting binding:profile by existing 
plugins you can look at two examples:
 – line 

 – line 

Regarding BPs for the CLI/API, we are planning to add vnic-type and profileid 
in the CLI, also the new keys in binding:profile. Are you saying no changes are 
needed (say display them, interpret the added cli arguments, etc), therefore no 
new BPs are needed for them?
[IrenaB] I think so. It should work bysetting on neutron port-create 
–binding:profile type=dict vnic_type=direct

Another thing is that we need to define the binding:profile dictionary.
[IrenaB] With regards to PCI SRIOV related attributes, right?

[ROBERT] yes.


On 1/29/14 4:02 AM, "Irena Berezovsky" 
<ire...@mellanox.com<mailto:ire...@mellanox.com>> wrote:

Will attend

From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Wednesday, January 29, 2014 12:55 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th

Hi Folks,

Can we have one more meeting tomorrow? I'd like to discuss the blueprints we 
are going to have and what each BP will be covering.

OpenStack-dev mailing list

Reply via email to