[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openvswitch-discuss
Subject:    [ovs-discuss] Kernel cache flow match error with linux bond portas physical NIC GRO on
From:       jingting () unitedstack ! com (=?utf-8?B?5bq35pWs5Lqt?=)
Date:       2016-02-29 3:08:40
Message-ID: tencent_4A816B3E1DC6D0F43CDA2650 () qq ! com
[Download RAW message or body]

Hi Gross:


I found the datapath flow generated correctly with LRO off,  and it seems GRO make no \
sense after I tried some different configuration of NIC with ethtool.


I'm confused with it. I think is totally different things between mod flow and NIC \
configuration.


Anyway, I will try the new version of ovs. Thanks!


 BR Jingting
 
------------------ Original ------------------
From:  "Jesse Gross"<jesse at kernel.org>;
Date:  Sat, Feb 27, 2016 06:09 AM
To:  "康敬亭"<jingting at unitedstack.com>; 
Cc:  "discuss"<discuss at openvswitch.org>; 
Subject:  Re: [ovs-discuss] Kernel cache flow match error with linux bond portas \
physical NIC GRO on

 
On Thu, Feb 25, 2016 at 11:06 PM, 康敬亭 <jingting at unitedstack.com> wrote:
> Hi guys:
> 
> I hava test environment as below:
> ENV: Neutron + ovs(2.1.2) with linux bond(eth2,eth3), vm in compute node
> couldn't get ip from dhcp server.
> 
> I had flow [1] added  in br-int, and with eth2 and eth3 GRO on, the kernel
> cache flow was [3],and packets droped. But with eth2 and eth3 GRO off, the
> kernel cache flow was[2], and the packets will be forward with pop_vlan, and
> works OK.
> 
> In the failed situation, I found error msg in log as below:
> openvswitch: netlink: Flow modification message rejected, unmasked key does
> not match.
> 
> Anyone have idea about what wrong about ovs does not works with the linux
> bond?
> OVS can't get field of vlan to match for packets from linux bond port with
> gro on?
> 
> BR
> Jingting
> 
> [1]  cookie=0x0, duration=1383.630s, table=0, n_packets=237, n_bytes=68899,
> idle_age=3, priority=3,in_port=37,dl_vlan=2001 actions=mod_vlan_vid:1,NORMAL
> 
> [2]skb_priority(0),in_port(6),eth(src=fa:16:3e:09:58:b6,dst=fa:16:3e:32:b3:d5),eth_t \
> ype(0x8100),vlan(vid=2001,pcp=0),encap(eth_type(0x0800),ipv4(src=172.30.248.4/0.0.0.0,dst=172.30.248.210/0.0.0.0,proto=17/0,tos=0xc0/0,ttl=64/0,frag=no/0xff)),
>  packets:0, bytes:0, used:never, actions:pop_vlan,7
> 
> [3]skb_priority(0),in_port(6),eth(src=fa:16:3e:09:58:b6,dst=fa:16:3e:32:b3:d5),eth_t \
> ype(0x8100),vlan(vid=2001/0xfff,pcp=0/0x0,cfi=1/1),encap(eth_type(0x0800),ipv4(src=1 \
> 72.30.248.4/0.0.0.0,dst=172.30.248.210/0.0.0.0,proto=17/0,tos=0xc0/0,ttl=64/0,frag=no/0xff)),
>  packets:0, bytes:0, used:never, actions:drop

These flows are very odd - for one thing, the basic incoming flow
without any mask applied is the same, meaning that it doesn't appear
that GRO is really having an effect (as it shouldn't) and another is
that they are overlapping, which is not allowed. Finally, the
wildcards in the second datapath flow doesn't make any sense given the
input OpenFlow flow.

I think the best thing to at this point is try a newer OVS version.
The specific warning that you mentioned has been fixed but more
generally, a lot of the flow generation code was in flux around 2.1
and things have calmed down since then.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/discuss/attachments/20160229/a26ba283/attachment-0001.html>



[prev in list] [next in list] [prev in thread] [next in thread]