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.
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.
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.
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
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.
Verified with following THT https://code.engineering.redhat.com/gerrit/gitweb?p=nfv-qe.git;a=tree;f=ospd-12-vlan-dpdk-two-ports-ctlplane-dataplane-bonding;h=e8a7616a6bda3f79e89aa7eccaf9996766f8d366;hb=refs/heads/ci
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