[ovs-dev] [PATCH v2 0/5] create tunnel devices using rtnetlink interface

Jesse Gross jesse at kernel.org
Fri Jun 10 16:11:39 UTC 2016


On Fri, Jun 10, 2016 at 2:37 AM, Thadeu Lima de Souza Cascardo
<cascardo at redhat.com> wrote:
> On Thu, Jun 09, 2016 at 09:49:15PM -0700, Jesse Gross wrote:
>> On Wed, Jun 8, 2016 at 11:21 AM, Thadeu Lima de Souza Cascardo
>> <cascardo at redhat.com> wrote:
>> > This series adds support for the creation of tunnels using the rtnetlink
>> > interface. This will open the possibility for new features and flags on those
>> > vports without the need to change vport compatibility code.
>> >
>> > Support for STT and LISP have not been added because these are not upstream yet,
>> > so we don't know how the interface will be like upstream. And there are no
>> > features in the current drivers right now we could make use of.
>> >
>> > We are able to set the MTU to UINT16_MAX since it is not restricted by the
>> > driver during newlink.
>>
>> The fact that the MTU can be set at link creation time is very nice -
>> I was surprised when I looked at the source to verify what was going
>> on.
>>
>> I did a little bit of testing with this series. For the basic case of
>> creating ports that didn't already exist, it worked well. However, it
>> had some problems with existing ports. There were two types that I ran
>> across:
>>
>> * When restarting OVS, it doesn't seem to be able to find and reuse
>> the existing tunnel ports. They end up getting removed from the
>> datapath and traffic doesn't pass.
>> * A little stranger one that I haven't been able to reproduce yet but
>> I suspect that relates to old state from a previous version of OVS
>> without this patch - I had a GRE port that already existed and when it
>> tried to start up it failed with thousands of error messages.
>>
>> In the kernel log:
>> [4263763.845236] net_ratelimit: 5861 callbacks suppressed
>> [4263763.845239] A link change request failed with some changes
>> committed already. Interface gre_sys may have been left with an
>> inconsistent configuration, please check.
>>
>> And in ovs-vswitchd.log:
>> 2016-06-10T04:03:19.768Z|01453|dpif|WARN|Dropped 1114 log messages in
>> last 1 seconds (most recently, 0 seconds ago) due to excessive rate
>> 2016-06-10T04:03:19.768Z|01454|dpif|WARN|system at ovs-system: failed to
>> add tun0 as port: File exists
>
> I guess I need the previous line that was dropped, or something referring to
> gre_sys instead of tun0.

It's just the same thing repeating over and over, there's no previous message:

2016-06-10T03:27:54.791Z|00019|bridge|INFO|ovs-vswitchd (Open vSwitch) 2.5.90
2016-06-10T03:28:04.791Z|00020|memory|INFO|6696 kB peak resident set
size after 10.0 seconds
2016-06-10T03:28:04.791Z|00021|memory|INFO|handlers:5 ports:2
revalidators:3 rules:5
2016-06-10T03:53:12.763Z|00022|dpif|WARN|system at ovs-system: failed to
add tun0 as port: File exists
2016-06-10T03:53:12.764Z|00023|dpif|WARN|system at ovs-system: failed to
add tun0 as port: File exists
2016-06-10T03:53:12.765Z|00024|dpif|WARN|system at ovs-system: failed to
add tun0 as port: File exists
2016-06-10T03:53:12.767Z|00025|dpif|WARN|system at ovs-system: failed to
add tun0 as port: File exists
2016-06-10T03:53:12.768Z|00026|dpif|WARN|system at ovs-system: failed to
add tun0 as port: File exists
2016-06-10T03:53:12.769Z|00027|dpif|WARN|system at ovs-system: failed to
add tun0 as port: File exists
2016-06-10T03:53:12.770Z|00028|dpif|WARN|system at ovs-system: failed to
add tun0 as port: File exists
2016-06-10T03:53:12.771Z|00029|dpif|WARN|system at ovs-system: failed to
add tun0 as port: File exists
2016-06-10T03:53:12.772Z|00030|dpif|WARN|system at ovs-system: failed to
add tun0 as port: File exists
2016-06-10T03:53:13.768Z|00031|dpif|WARN|Dropped 1221 log messages in
last 1 seconds (most recently, 0 seconds ago) due to excessive rate
2016-06-10T03:53:13.768Z|00032|dpif|WARN|system at ovs-system: failed to
add tun0 as port: File exists
2016-06-10T03:53:14.768Z|00033|dpif|WARN|Dropped 1200 log messages in
last 1 seconds (most recently, 0 seconds ago) due to excessive rate
2016-06-10T03:53:14.768Z|00034|dpif|WARN|system at ovs-system: failed to
add tun0 as port: File exists
[...]

tun0 is type GRE, so gre_sys is it's backing port.

>>
>> Can you take a look at these and also maybe do some more testing in
>> these types of edge scenarios?
>
> I will. On the previous version, I remember testing an upgrade from OVS without
> the patch to OVS with the patch. I will look into those issues and test both a
> restart and an upgrade scenario on some different kernels.

One area that also came to mind is how changes to tunnel protocols in
the backported module of OVS should be handled. Currently, this code
will never pick them up - it will just fall back to the compatibility
layer. (This isn't an issue right now but imagine a new feature that
gets added upstream - such as VXLAN-GPE - there won't be any way to
access it on older kernels.)



More information about the dev mailing list