[ovs-discuss] detecting supported port types and enabling dpdk datapaths in OpenStack

Mooney, Sean K sean.k.mooney at intel.com
Thu Jul 24 12:44:56 UTC 2014


Hi,
While probing would determine if a feature exists I'm not sure it could be done with the current OpenStack workflow.

In OpenStack the decision of what interface to use is made by neutron(networking project)  however adding the port to and ovs bridge
Is done by nova(compute project) when a vm Is booted.

Because of this workflow neutron needs to determine if a port type is supported / if dpdk is available before a port is created.
Without dramatically changing the workflow in OpenStack neutron would have to perform  a future probe via ovsdb/ovs-vsctl without creating a port.
Do you know if such a feature probe is currently possible?

If the netdev structure was extended to contain a static  list of supported datapaths it would allow for the association between netdev and datapaths to be tracked.
When the vswitch starts it could then update the bridge table by calling netdev_enumerate_types() and adding only the netdevs that re support by the bridge datapath
To the supported_port_types field.  If the datapath of a bridge is changed this field would have to be updated accordingly.

This would allow open daylight to check the supported port types without requiring an agent on the node via ovsdb.
Neutron could similarly retrieve the same Information via ovs-vsctl using its agent.

I am not familiar enough with Open vSwitch to judge the impact/scope of making this change but from a high level would coupling netdevs an datapaths in this way be
Possible/ appropriate.

Having this information would allow Open vSwitch to catch configuration error such as trying to use a dpdk physical port with the kernel datapath or creating
A gre/vxlan netdev with the userspce build of Open vSwitch. That is out of scope of simply reporting the supported port types but having this information could enable
Other usecases too.


Regards
sean

-----Original Message-----
From: Ben Pfaff [mailto:blp at nicira.com] 
Sent: Wednesday, July 23, 2014 6:11 PM
To: Mooney, Sean K
Cc: discuss at openvswitch.org
Subject: Re: [ovs-discuss] detecting supported port types and enabling dpdk datapaths in OpenStack

On Wed, Jul 23, 2014 at 03:46:24PM +0000, Mooney, Sean K wrote:
> 1.            The command line of the ovs-vSwitchd process could be stored in the ovsdb. (least preferable option,  but smallest change)
> 2.            The datapath type of the DPDK build could be changed to NETDEV-DPDK (better, but not optimal)
> 3.            The bridge table in the ovsdb  could be extended with a supported_port_types field.

Of those options, #3 seems the best to me too.

It is easy for Open vSwitch to internally enumerate all of the types of netdevs it supports (just call netdev_enumerate_types()).  It's more difficult to figure out which types of datapaths support particular netdev types, since netdevs aren't tied directly to datapaths.  It might be appropriate to couple netdevs more closely to datapaths, I would not want to just have each datapath provide a list (e.g. in the form of a set of strings), because that could easily get out of sync.

When other factors don't rule it out, it's ideal to probe for a feature by trying it to see whether it works, because that isn't sensitive to false positives or false negatives due to incorrect capabilities announced by the software being tested.  (This is the same philosophy as Autoconf.)  Have you considered using a feature probe, by simply trying to use the feature that you want to use from OpenStack?
--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.





More information about the discuss mailing list