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:[email protected]] 
Sent: Wednesday, July 23, 2014 6:11 PM
To: Mooney, Sean K
Cc: [email protected]
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.


_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss

Reply via email to