[openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th
Robert Li (baoli)
baoli at cisco.com
Wed Jan 29 22:44:37 UTC 2014
that's a good find. profileid as part of IEEE 802.1br needs to be in
binding:profile, and can be specified by a normal user, and later possibly
the pci_flavor. Would it be wrong to say something as in below in the
If it's not appropriate, then I agree with you we may need another
On 1/29/14 4:57 PM, "Robert Kukura" <rkukura at redhat.com> wrote:
>On 01/29/2014 09:46 AM, Robert Li (baoli) wrote:
>> 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.
>I'd phrase that choice as "top-level attribute" vs. "key/value pair
>within the binding:profile attribute". If we go with a new top-level
>attribute, it may or may not end up being part of the portbindings
>Although I've been advocating making vnic_type a key within
>binding:profile (minimizing effort), it just occurred to me that
> "create_port:binding:profile": "rule:admin_only",
> "get_port:binding:profile": "rule:admin_only",
> "update_port:binding:profile": "rule:admin_only",
>This means that only administrative users (including nova's integration
>with neutron) can read or write the binding:profile attribute by default.
>But my (limited) understanding of the PCI-passthru use cases is that
>normal users need to specify vnic_type because this is what determines
>the NIC type that their VMs see for the port. If that is correct, then I
>think this tips the balance towards vnic_type being a new top-level
>attribute to which normal users have read/write access. Comments?
>If I'm mistaken on the above, please ignore the rest of this email...
>If vnic_type is a new top-level attribute accessible to normal users,
>then I'm not sure it belongs in the portbindings extension. First,
>everything else in that extension is only visible to administrative
>users. Second, from the normal user's point of view, vnic_type has to do
>with the type of NIC they want within their VM, not with how the port is
>bound outside their VM to some underlying network segment and networking
>mechanism they aren't even aware of. So we need a new extension for
>vnic_type, which has the advantage of not requiring any change to
>existing plugins that don't support that extension.
>If vnic_type is a new top-level attribute in a new API extension, it
>deserves its own neutron BP covering defining the extension and
>implementing it in ML2. This is probably an update of Irena's
>Implementations for other plugins could follow via separate BPs as they
>choose to implement the extension.
>If anything else we've been planning to put in binding:profile needs
>normal user access, it could be defined in this new extension instead.
>For now, I'm assuming other input data for PCI-passthru (such as the
>slot info from nova) is only accessible to administrators and will go in
>binding:profile. I'll submit a separate BP for generically implementing
>the binding:profile attribute in ML2, as we've discussed.
>This leaves us with potentially 3 separate generic neutron/Ml2 BPs
>providing the infrastructure for PCI-passthru:
>2) My BP to implement binding:profile in ML2
>3) Definition/implementation of binding:vif_details based on Nachi's
>binding:vif_security patch, for which I could submit a BP.
More information about the OpenStack-dev