linux-toradex.git/net/openvswitch, branch v4.9-rc3

openvswitch: add NETIF_F_HW_VLAN_STAG_TX to internal dev

2016-10-13T14:03:23+00:00

The internal device does support 802.1AD offloading since 018c1dda5ff1
("openvswitch: 802.1AD Flow handling, actions, vlan parsing, netlink
attributes").

Signed-off-by: Jiri Benc 
Acked-by: Pravin B Shelar 
Acked-by: Eric Garver 
Signed-off-by: David S. Miller

openvswitch: fix vlan subtraction from packet length

2016-10-13T14:03:23+00:00

When the packet has its vlan tag in skb->vlan_tci, the length of the VLAN
header is not counted in skb->len. It doesn't make sense to subtract it.

Fixes: 018c1dda5ff1 ("openvswitch: 802.1AD Flow handling, actions, vlan parsing, netlink attributes")
Signed-off-by: Jiri Benc 
Acked-by: Pravin B Shelar 
Acked-by: Eric Garver 
Signed-off-by: David S. Miller

openvswitch: vlan: remove wrong likely statement

2016-10-13T14:03:23+00:00

This code is called whenever flow key is being extracted from the packet.
The packet may be as likely vlan tagged as not.

Fixes: 018c1dda5ff1 ("openvswitch: 802.1AD Flow handling, actions, vlan parsing, netlink attributes")
Signed-off-by: Jiri Benc 
Acked-by: Pravin B Shelar 
Acked-by: Eric Garver 
Signed-off-by: David S. Miller

openvswitch: use mpls_hdr

2016-10-03T06:00:22+00:00

skb_mpls_header is equivalent to mpls_hdr now. Use the existing helper
instead.

Signed-off-by: Jiri Benc 
Acked-by: Pravin B Shelar 
Signed-off-by: David S. Miller

openvswitch: mpls: set network header correctly on key extract

2016-10-03T06:00:21+00:00

After the 48d2ab609b6b ("net: mpls: Fixups for GSO"), MPLS handling in
openvswitch was changed to have network header pointing to the start of the
MPLS headers and inner_network_header pointing after the MPLS headers.

However, key_extract was missed by the mentioned commit, causing incorrect
headers to be set when a MPLS packet just enters the bridge or after it is
recirculated.

Fixes: 48d2ab609b6b ("net: mpls: Fixups for GSO")
Signed-off-by: Jiri Benc 
Acked-by: Pravin B Shelar 
Signed-off-by: David S. Miller

openvswitch: avoid resetting flow key while installing new flow.

2016-09-21T02:54:35+00:00

since commit commit db74a3335e0f6 ("openvswitch: use percpu
flow stats") flow alloc resets flow-key. So there is no need
to reset the flow-key again if OVS is using newly allocated
flow-key.

Signed-off-by: Pravin B Shelar 
Signed-off-by: David S. Miller

openvswitch: Fix Frame-size larger than 1024 bytes warning.

2016-09-21T02:54:35+00:00

There is no need to declare separate key on stack,
we can just use sw_flow->key to store the key directly.

This commit fixes following warning:

net/openvswitch/datapath.c: In function ‘ovs_flow_cmd_new’:
net/openvswitch/datapath.c:1080:1: warning: the frame size of 1040 bytes
is larger than 1024 bytes [-Wframe-larger-than=]

Signed-off-by: Pravin B Shelar 
Signed-off-by: David S. Miller

openvswitch: use percpu flow stats

2016-09-19T02:14:01+00:00

Instead of using flow stats per NUMA node, use it per CPU. When using
megaflows, the stats lock can be a bottleneck in scalability.

On a E5-2690 12-core system, usual throughput went from ~4Mpps to
~15Mpps when forwarding between two 40GbE ports with a single flow
configured on the datapath.

This has been tested on a system with possible CPUs 0-7,16-23. After
module removal, there were no corruption on the slab cache.

Signed-off-by: Thadeu Lima de Souza Cascardo 
Cc: pravin shelar 
Acked-by: Pravin B Shelar 
Signed-off-by: David S. Miller

openvswitch: fix flow stats accounting when node 0 is not possible

2016-09-19T02:14:01+00:00

On a system with only node 1 as possible, all statistics is going to be
accounted on node 0 as it will have a single writer.

However, when getting and clearing the statistics, node 0 is not going
to be considered, as it's not a possible node.

Tested that statistics are not zero on a system with only node 1
possible. Also compile-tested with CONFIG_NUMA off.

Signed-off-by: Thadeu Lima de Souza Cascardo 
Acked-by: Pravin B Shelar 
Signed-off-by: David S. Miller

openvswitch: avoid deferred execution of recirc actions

2016-09-16T00:35:52+00:00

The ovs kernel data path currently defers the execution of all
recirc actions until stack utilization is at a minimum.
This is too limiting for some packet forwarding scenarios due to
the small size of the deferred action FIFO (10 entries). For
example, broadcast traffic sent out more than 10 ports with
recirculation results in packet drops when the deferred action
FIFO becomes full, as reported here:

     http://openvswitch.org/pipermail/dev/2016-March/067672.html

Since the current recursion depth is available (it is already tracked
by the exec_actions_level pcpu variable), we can use it to determine
whether to execute recirculation actions immediately (safe when
recursion depth is low) or defer execution until more stack space is
available.

With this change, the deferred action fifo size becomes a non-issue
for currently failing scenarios because it is no longer used when
there are three or fewer recursions through ovs_execute_actions().

Suggested-by: Pravin Shelar 
Signed-off-by: Lance Richardson 
Acked-by: Pravin B Shelar 
Signed-off-by: David S. Miller