Hi, For the current Openstack development cycle (JUNO) we are trying to enable Openstack to allow virtual machines to utilise the DPDK based userspace vhost interface.
As part of enabling DPDK accelerated datapaths in the neutron and opendaylight, a detection mechanism is required to determine the supported port types of the nodes Open vSwitch. I would like to ask for input on how we can best perform this detection, in particular if DPDK is being used and which port types are supported by a given ovs bridge datapath. The proposed detection mechanism we would like to use is as follows: 1. Neutron detects if the hypervisor on the compute node is QEMU. If not, dpdk accelerated datapaths are not supported. 2. Neutron then detects the datapath of the ovs bridge. a. if the datapath is DPDK, then the Intel (R) DPDK vSwitch is installed and dpdk ports such as userspace vhost and ivshmem are supported. b. if the datapath is NETDEV, an additional test is performed to test if a standard or DPDK NETDEV datapath is used. i. to detect if DPDK is used, the command line of the vSwitchd process is checked for the presence of --DPDK. ii. If -- DPDK is present the DPDK NETDEV datapath is used c. if the datapath is not DPDK or NETDEV, dpdk ports are not supported The detection strategy above has several drawbacks in its current form as it requires access to the compute node to check the command line the vSwitchd process is launched with. When Openstack manages open vSwitch directly, the Open vSwitch agent can perform this check. However, opendaylight does not have an agent running on the compute node. As such opendaylight cannot perform step 2b. To simplify detection in future Open vSwitch versions I would like to propose a change to Open vSwitch. At present I have identified three modifications options that could be made to enable the opendaylight use case and to simplify the detection mechanism as follows: 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. note: DPDK below is referring to a DPDK physical port. * when ovs-vSwitchd starts it would update the supported port types for each bridge based on the datapath type and the command line it was launched with. (optimal solution) * If the datapath is changed at runtime the value would also be updated accordingly * Open vSwitch: using the kernel datapath the supported port types would be: kernel vhost, veth, physical * Open vSwitch with DPDK: the supported port types would be: kernel vhost, veth, physical, ivshmem, DPDKvhost, DPDK * Intel DPDK vswtich: the supported port types would be : ivshmem, DPDK vhost, DPDK Feedback on how to improve the detection mechanism above and report switch capabilities such as supported port types would be appreciated. Regards, Sean Intel corporation -------------------------------------------------------------- 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
