Bug 1416430 - OVS-DPDK 2.7 support
Summary: OVS-DPDK 2.7 support
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: os-net-config
Version: 12.0 (Pike)
Hardware: x86_64
OS: Linux
urgent
high
Target Milestone: Upstream M3
: 12.0 (Pike)
Assignee: Karthik Sundaravel
QA Contact: Yariv
URL:
Whiteboard:
Depends On: 1335865 1411445 1486127
Blocks: 1426175 1469612
TreeView+ depends on / blocked
 
Reported: 2017-01-25 13:26 UTC by Franck Baudin
Modified: 2018-02-05 19:04 UTC (History)
15 users (show)

Fixed In Version: os-net-config-7.3.1-0.20170926013247.9ce34d5.el7ost openstack-tripleo-heat-templates-7.0.1-0.20170927205938.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-13 21:04:11 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenStack gerrit 480540 0 None MERGED OvS 2.7 support - dpdk-devargs needs to provided for DPDK devices 2021-01-16 21:20:19 UTC
OpenStack gerrit 483846 0 None MERGED Enable Dpdk after rebooting with Hugepages for OvS2.7 2021-01-16 21:19:40 UTC
Red Hat Product Errata RHEA-2017:3462 0 normal SHIPPED_LIVE Red Hat OpenStack Platform 12.0 Enhancement Advisory 2018-02-16 01:43:25 UTC

Description Franck Baudin 2017-01-25 13:26:48 UTC
Description of problem:
Assuming that TripleO supports OVS-DPDK 2.6 (work in progress, tacked in another BZ), supporting OVS 2.7 will requires additional changes, as per OVS release note (NEW file):

   - DPDK:
     * New option 'n_rxq_desc' and 'n_txq_desc' fields for DPDK interfaces
       which set the number of rx and tx descriptors to use for the given port.
     * Support for DPDK v16.11.
     * Support for rx checksum offload. Refer DPDK HOWTO for details.
     * Port Hotplug is now supported.
[name]* DPDK physical ports can now have arbitrary names. The PCI address of
       the device must be set using the 'dpdk-devargs' option. Compatibility
       with the old dpdk<portid> naming scheme is broken, and as such a
       device will not be available for use until a valid dpdk-devargs is
       specified.
     * Virtual DPDK Poll Mode Driver (vdev PMD) support.

At least the [name] will impact TripleO. And OVS 2.7 may land with RHEL 7.4 (TBC), and will impact all existing versions from RHOSP10 included.

Expected results:
Deploy OVS-DPDK 2.7, with a feature parity with OVS 2.6.

Comment 1 Vijay Chundury 2017-01-27 09:43:09 UTC
Franck,
We will have to look into configurability of the new features introduced in OVS2.6 and i believe this will not be a continuation. We can only confirm the effort when we are able to manually upgrade to 2.7 to test these features.

I believe the feature to have port-name would mean an interface change that will have implications with backward compatibility to OSP10 puddle.
This is good information to have but i dont think we should target this for OSP12.
Having this information will help us plan better for sure.

Comment 3 Vijay Chundury 2017-04-24 10:35:05 UTC
Franck,
I've pushed the migration work of OVS2.7 (esp to build the feasibility study around changes required in our installer) for OSP13 release and we would raise the BP's at the appropriate time.

Comment 4 Saravanan KR 2017-07-03 12:25:24 UTC
Updating the last discussion:
------------------------------

With OvS2.7 release notes, we read below section:

     * DPDK physical ports can now have arbitrary names. The PCI address of
       the device must be set using the 'dpdk-devargs' option. Compatibility
       with the old dpdk<portid> naming scheme is broken, and as such a
       device will not be available for use until a valid dpdk-devargs is
       specified.

It looks like we need to provide additional configuration for DPDK
port name. Below is the command:

ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk \
     options:dpdk-devargs=0000:01:00.0

For OSP, we are using os-net-config, which creates the ifcfg files.
These ifcfg files will be used to create DPDK ports via ifup-ovs
script [1]. We don't see the support has been enhanced for ifup-ovs
for the new argument. For both DPDK port and DPDK bond, is there any
change required in ifup-ovs [or] any another alternative?

----------------------------------------------------------------

I believe you could use:

OVS_EXTRA="set interface <name> options:dpdk-devargs=0000:01:00.0"

-----------------------------------------------------------------

This is the current value of ifcfg for DPDK port -
http://paste.openstack.org/show/614142/

The suggestion is to add like
OVS_EXTRA="options:dpdk-devargs=0000:01:00.0 -- set Interface $DEVICE
mtu_request=$MTU -- set Interface $DEVICE options:n_rxq=$RX_QUEUE"

When ifup-ovs reads OVS_EXTRA, it will append to the command with
"--". We cannot add the options:dpdk-devargs alone to extra. Can we
add the complete format as suggested by Flavio, like
OVS_EXTRA="set Interface $DEVICE options:dpdk-devargs=0000:01:00.0 --
set Interface $DEVICE mtu_request=$MTU -- set Interface $DEVICE
options:n_rxq=$RX_QUEUE"

If we add this way, then the same can be applicable for OVSDPDKBond
[1] type too. Please confirm whether this is approach is OK?

Regards,
Saravanan KR

[1] https://github.com/openvswitch/ovs/blob/master/rhel/etc_sysconfig_network-scripts_ifup-ovs#L200

Comment 5 Flavio Leitner 2017-07-05 17:25:52 UTC
That would be the solution for now.  We might be able to improve ifcfg- config style or move on to systemd-network or NetworkManager.  That is not clear yet.

Comment 16 errata-xmlrpc 2017-12-13 21:04:11 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:3462


Note You need to log in before you can comment on or make changes to this bug.