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"<je...@kernel.org>;
Date: Sat, Feb 27, 2016 06:09 AM
To: "康敬亭"<jingt...@unitedstack.com>;
Cc: "discuss"<discuss@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, 康敬亭 <jingt...@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_type(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_type(0x8100),vlan(vid=2001/0xfff,pcp=0/0x0,cfi=1/1),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: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.
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
