Bug 1469839 - OSP 10z3 with OVS-DPDK and jumbo frames cannot set dpdk0 interface MTU
OSP 10z3 with OVS-DPDK and jumbo frames cannot set dpdk0 interface MTU
Status: CLOSED NOTABUG
Product: Red Hat OpenStack
Classification: Red Hat
Component: os-net-config (Show other bugs)
10.0 (Newton)
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: RHOS Maint
Shai Revivo
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-11 20:04 EDT by Andreas Karis
Modified: 2017-08-21 09:14 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-17 07:26:26 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
my templates (8.81 KB, application/x-gzip)
2017-07-13 10:24 EDT, Andreas Karis
no flags Details

  None (edit)
Description Andreas Karis 2017-07-11 20:04:25 EDT
Following suggestions in: https://bugzilla.redhat.com/show_bug.cgi?id=1457384 , comment 7:
~~~
We have tested MTU in OSP11 with the below nic configs in compute.yaml
  -
    type: ovs_user_bridge
    name: br-link1
    use_dhcp: false
    members:
      -
        type: ovs_dpdk_port
        name: dpdk1
        mtu: 2000
        ovs_extra:
          - set interface $DEVICE mtu_request=$MTU
        members:
          -
            type: interface
            name: nic5

And in network-environment.yaml
NeutronGlobalPhysnetMtu: 2000
~~~


Note that we already have separate bug reports for changes to neutron os-vif:
https://bugzilla.redhat.com/show_bug.cgi?id=1468620
https://bugzilla.redhat.com/show_bug.cgi?id=1447081

This issue here however is about problems with the dpdk0 port (tripleo / os-net-config???) 

I finally got a chance to test this in my lab and:
~~~
[root@overcloud-compute-0 ~]# ovs-vsctl list interface vhuc940174f-25  | grep mtu
mtu                 : 1500
mtu_request         : []
~~~

What surprised me was that:
~~~
[root@overcloud-compute-0 ~]# ovs-vsctl list interface dpdk0  | grep mtu
mtu                 : 1500
mtu_request         : []
~~~

Whereas the MTU modification obviously worked for the rest:
~~~
[root@overcloud-compute-0 ~]# ip link ls | grep 2000
10: br-link: <BROADCAST,PROMISC,UP,LOWER_UP> mtu 2000 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 1000
[root@overcloud-compute-0 ~]# grep global_physnet_mtu /etc/neutron/neutron.conf 
#global_physnet_mtu = 1500
global_physnet_mtu=2000
~~~

Which means that even this in the templates didn't work in my case:
~~~
templates/nic-configs/compute.yaml-            -
templates/nic-configs/compute.yaml-              type: ovs_user_bridge
templates/nic-configs/compute.yaml-              name: br-link
templates/nic-configs/compute.yaml:              mtu: 2000
templates/nic-configs/compute.yaml-              ovs_extra:
templates/nic-configs/compute.yaml:                - set interface $DEVICE mtu_request=$MTU
templates/nic-configs/compute.yaml-              use_dhcp: false
templates/nic-configs/compute.yaml-              members:
~~~

In OSP 10z3, we need a backport of whatever applies these template settings:
~~~
        mtu: 2000
        ovs_extra:
          - set interface $DEVICE mtu_request=$MTU
~~~

Thanks,

Andreas
Comment 2 Andreas Karis 2017-07-13 10:24 EDT
Created attachment 1297686 [details]
my templates
Comment 3 Andreas Karis 2017-07-13 10:25:00 EDT
I just realized that the template format between OSP 10 and OSP 11 changed. OSP 10 by default still uses OS::Heat::StructuredConfig - may this be the issue, and may I need to use something similar to:
{get_param: MTU}
{get_param: DEVICE}
instead? However, these are obviously not in the parameter list, so some other modification may be needed ...
Comment 4 Andreas Karis 2017-07-14 10:57:30 EDT
Karthik, thanks, this was a code 18.

With fixed templates:
            -
              type: ovs_user_bridge
              name: br-link
              use_dhcp: false
              members:
                -
                  type: ovs_dpdk_port
                  name: dpdk0
                  mtu: 2000
                  ovs_extra:
                    - set interface $DEVICE mtu_request=$MTU
                  members:
                    -
                      type: interface
                      name: enp181s0
                      # name: enp201s0

This works:

[root@overcloud-compute-0 ~]# ovs-vsctl show
8a9a2a4c-e75d-45b2-87eb-6388fd79fe0c
    Manager "ptcp:6640:127.0.0.1"
        is_connected: true
    Bridge br-link
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port phy-br-link
            Interface phy-br-link
                type: patch
                options: {peer=int-br-link}
        Port br-link
            Interface br-link
                type: internal
        Port "dpdk0"
            Interface "dpdk0"
                type: dpdk
    Bridge br-int
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port br-int
            Interface br-int
                type: internal
        Port int-br-link
            Interface int-br-link
                type: patch
                options: {peer=phy-br-link}
    ovs_version: "2.6.1"
[root@overcloud-compute-0 ~]# ovs-vsctl list interface dpdk0 | grep mtu
mtu                 : 2000
mtu_request         : 2000


Please go ahead and close this.
Comment 5 Vijay Chundury 2017-07-17 07:26:26 EDT
For the benefit of the wider audience: Adding Jim/Vincent from the sprint team to this BZ.

When this BZ was listed in the RHOS-PRIO, we made these statements:
For the benefit of the wider audience:
A. We would need the os-vif back port from compute DFG, this would enable the MTU setting on the vhost-user ports (Guest VM) for the end to end feature completion.
Compute DFG is aware of this backporting effort and their target to get this done for 10z4 (updated in the BZ):


B. We need an answer from Sprint folks to the above question, this would clarify that we at the NFV DFG would have to backport the os-net-config  change.
We discussed this at the DFG and in the sprint call to see if the above manual change was okay and we can move on. We havent heard back from the sprint account team as mentioned.
Any way We've targeted this backport for our 10z4 release.

C. In the sprint call, i volunteered to write these steps and provide end-to-end DEV testing is done post A&B, for the benefit of the sprint consultant.
Similar to https://bugzilla.redhat.com/show_bug.cgi?id=1457384#c7. 

This particular BZ tracks (B) & (C) and as Andreas mentions this is taken care. (A) is still pending. 
This BZ is primarily opened for (B) && (C) hence closing it as suggested.

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