2019-05-29 17:12:43 +03:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2011-10-26 06:26:31 +04:00
|
|
|
/*
|
2014-09-16 06:37:25 +04:00
|
|
|
* Copyright (c) 2007-2014 Nicira, Inc.
|
2011-10-26 06:26:31 +04:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/uaccess.h>
|
|
|
|
#include <linux/netdevice.h>
|
|
|
|
#include <linux/etherdevice.h>
|
|
|
|
#include <linux/if_ether.h>
|
|
|
|
#include <linux/if_vlan.h>
|
|
|
|
#include <net/llc_pdu.h>
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/jhash.h>
|
|
|
|
#include <linux/jiffies.h>
|
|
|
|
#include <linux/llc.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/in.h>
|
|
|
|
#include <linux/rcupdate.h>
|
2016-09-16 01:11:53 +03:00
|
|
|
#include <linux/cpumask.h>
|
2011-10-26 06:26:31 +04:00
|
|
|
#include <linux/if_arp.h>
|
|
|
|
#include <linux/ip.h>
|
|
|
|
#include <linux/ipv6.h>
|
2014-10-06 16:05:13 +04:00
|
|
|
#include <linux/mpls.h>
|
2013-08-22 23:30:48 +04:00
|
|
|
#include <linux/sctp.h>
|
2013-10-30 04:22:21 +04:00
|
|
|
#include <linux/smp.h>
|
2011-10-26 06:26:31 +04:00
|
|
|
#include <linux/tcp.h>
|
|
|
|
#include <linux/udp.h>
|
|
|
|
#include <linux/icmp.h>
|
|
|
|
#include <linux/icmpv6.h>
|
|
|
|
#include <linux/rculist.h>
|
|
|
|
#include <net/ip.h>
|
2013-06-18 04:50:18 +04:00
|
|
|
#include <net/ip_tunnels.h>
|
2011-10-26 06:26:31 +04:00
|
|
|
#include <net/ipv6.h>
|
2014-10-06 16:05:13 +04:00
|
|
|
#include <net/mpls.h>
|
2011-10-26 06:26:31 +04:00
|
|
|
#include <net/ndisc.h>
|
2017-11-07 16:07:02 +03:00
|
|
|
#include <net/nsh.h>
|
2022-02-03 11:44:30 +03:00
|
|
|
#include <net/pkt_cls.h>
|
2021-12-14 20:24:35 +03:00
|
|
|
#include <net/netfilter/nf_conntrack_zones.h>
|
2011-10-26 06:26:31 +04:00
|
|
|
|
2015-08-30 03:44:08 +03:00
|
|
|
#include "conntrack.h"
|
2014-09-16 06:20:31 +04:00
|
|
|
#include "datapath.h"
|
|
|
|
#include "flow.h"
|
|
|
|
#include "flow_netlink.h"
|
2015-08-30 03:44:08 +03:00
|
|
|
#include "vport.h"
|
2014-09-16 06:20:31 +04:00
|
|
|
|
2013-10-04 05:16:47 +04:00
|
|
|
u64 ovs_flow_used_time(unsigned long flow_jiffies)
|
2013-08-08 07:01:00 +04:00
|
|
|
{
|
2017-11-27 14:41:38 +03:00
|
|
|
struct timespec64 cur_ts;
|
2013-10-04 05:16:47 +04:00
|
|
|
u64 cur_ms, idle_ms;
|
2013-08-08 07:01:00 +04:00
|
|
|
|
2017-11-27 14:41:38 +03:00
|
|
|
ktime_get_ts64(&cur_ts);
|
2013-10-04 05:16:47 +04:00
|
|
|
idle_ms = jiffies_to_msecs(jiffies - flow_jiffies);
|
2017-11-27 14:41:38 +03:00
|
|
|
cur_ms = (u64)(u32)cur_ts.tv_sec * MSEC_PER_SEC +
|
2013-10-04 05:16:47 +04:00
|
|
|
cur_ts.tv_nsec / NSEC_PER_MSEC;
|
2013-08-08 07:01:00 +04:00
|
|
|
|
2013-10-04 05:16:47 +04:00
|
|
|
return cur_ms - idle_ms;
|
2013-08-28 00:02:21 +04:00
|
|
|
}
|
|
|
|
|
2013-10-23 12:40:44 +04:00
|
|
|
#define TCP_FLAGS_BE16(tp) (*(__be16 *)&tcp_flag_word(tp) & htons(0x0FFF))
|
2013-08-08 07:01:00 +04:00
|
|
|
|
2014-05-07 03:48:38 +04:00
|
|
|
void ovs_flow_stats_update(struct sw_flow *flow, __be16 tcp_flags,
|
2014-11-06 17:58:52 +03:00
|
|
|
const struct sk_buff *skb)
|
2013-08-08 07:01:00 +04:00
|
|
|
{
|
2019-07-19 19:20:13 +03:00
|
|
|
struct sw_flow_stats *stats;
|
openvswitch: Optimize operations for OvS flow_stats.
When calling the flow_free() to free the flow, we call many times
(cpu_possible_mask, eg. 128 as default) cpumask_next(). That will
take up our CPU usage if we call the flow_free() frequently.
When we put all packets to userspace via upcall, and OvS will send
them back via netlink to ovs_packet_cmd_execute(will call flow_free).
The test topo is shown as below. VM01 sends TCP packets to VM02,
and OvS forward packtets. When testing, we use perf to report the
system performance.
VM01 --- OvS-VM --- VM02
Without this patch, perf-top show as below: The flow_free() is
3.02% CPU usage.
4.23% [kernel] [k] _raw_spin_unlock_irqrestore
3.62% [kernel] [k] __do_softirq
3.16% [kernel] [k] __memcpy
3.02% [kernel] [k] flow_free
2.42% libc-2.17.so [.] __memcpy_ssse3_back
2.18% [kernel] [k] copy_user_generic_unrolled
2.17% [kernel] [k] find_next_bit
When applied this patch, perf-top show as below: Not shown on
the list anymore.
4.11% [kernel] [k] _raw_spin_unlock_irqrestore
3.79% [kernel] [k] __do_softirq
3.46% [kernel] [k] __memcpy
2.73% libc-2.17.so [.] __memcpy_ssse3_back
2.25% [kernel] [k] copy_user_generic_unrolled
1.89% libc-2.17.so [.] _int_malloc
1.53% ovs-vswitchd [.] xlate_actions
With this patch, the TCP throughput(we dont use Megaflow Cache
+ Microflow Cache) between VMs is 1.18Gbs/sec up to 1.30Gbs/sec
(maybe ~10% performance imporve).
This patch adds cpumask struct, the cpu_used_mask stores the cpu_id
that the flow used. And we only check the flow_stats on the cpu we
used, and it is unncessary to check all possible cpu when getting,
cleaning, and updating the flow_stats. Adding the cpu_used_mask to
sw_flow struct does’t increase the cacheline number.
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-18 09:28:06 +03:00
|
|
|
unsigned int cpu = smp_processor_id();
|
2015-01-13 19:13:44 +03:00
|
|
|
int len = skb->len + (skb_vlan_tag_present(skb) ? VLAN_HLEN : 0);
|
2013-08-08 07:01:00 +04:00
|
|
|
|
2016-09-16 01:11:53 +03:00
|
|
|
stats = rcu_dereference(flow->stats[cpu]);
|
2013-10-30 04:22:21 +04:00
|
|
|
|
2016-09-16 01:11:53 +03:00
|
|
|
/* Check if already have CPU-specific stats. */
|
openvswitch: Per NUMA node flow stats.
Keep kernel flow stats for each NUMA node rather than each (logical)
CPU. This avoids using the per-CPU allocator and removes most of the
kernel-side OVS locking overhead otherwise on the top of perf reports
and allows OVS to scale better with higher number of threads.
With 9 handlers and 4 revalidators netperf TCP_CRR test flow setup
rate doubles on a server with two hyper-threaded physical CPUs (16
logical cores each) compared to the current OVS master. Tested with
non-trivial flow table with a TCP port match rule forcing all new
connections with unique port numbers to OVS userspace. The IP
addresses are still wildcarded, so the kernel flows are not considered
as exact match 5-tuple flows. This type of flows can be expected to
appear in large numbers as the result of more effective wildcarding
made possible by improvements in OVS userspace flow classifier.
Perf results for this test (master):
Events: 305K cycles
+ 8.43% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 5.64% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 4.75% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 3.32% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 2.61% ovs-vswitchd [kernel.kallsyms] [k] pcpu_alloc_area
+ 2.19% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.03% swapper [kernel.kallsyms] [k] intel_idle
+ 1.84% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 1.64% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.58% ovs-vswitchd libc-2.15.so [.] 0x7f4e6
+ 1.07% ovs-vswitchd [kernel.kallsyms] [k] memset
+ 1.03% netperf [kernel.kallsyms] [k] __ticket_spin_lock
+ 0.92% swapper [kernel.kallsyms] [k] __ticket_spin_lock
...
And after this patch:
Events: 356K cycles
+ 6.85% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 4.63% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 3.06% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 2.81% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.51% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 2.27% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.84% ovs-vswitchd libc-2.15.so [.] 0x15d30f
+ 1.74% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 1.47% swapper [kernel.kallsyms] [k] intel_idle
+ 1.34% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask
+ 1.33% ovs-vswitchd ovs-vswitchd [.] rule_actions_unref
+ 1.16% ovs-vswitchd ovs-vswitchd [.] hindex_node_with_hash
+ 1.16% ovs-vswitchd ovs-vswitchd [.] do_xlate_actions
+ 1.09% ovs-vswitchd ovs-vswitchd [.] ofproto_rule_ref
+ 1.01% netperf [kernel.kallsyms] [k] __ticket_spin_lock
...
There is a small increase in kernel spinlock overhead due to the same
spinlock being shared between multiple cores of the same physical CPU,
but that is barely visible in the netperf TCP_CRR test performance
(maybe ~1% performance drop, hard to tell exactly due to variance in
the test results), when testing for kernel module throughput (with no
userspace activity, handful of kernel flows).
On flow setup, a single stats instance is allocated (for the NUMA node
0). As CPUs from multiple NUMA nodes start updating stats, new
NUMA-node specific stats instances are allocated. This allocation on
the packet processing code path is made to never block or look for
emergency memory pools, minimizing the allocation latency. If the
allocation fails, the existing preallocated stats instance is used.
Also, if only CPUs from one NUMA-node are updating the preallocated
stats instance, no additional stats instances are allocated. This
eliminates the need to pre-allocate stats instances that will not be
used, also relieving the stats reader from the burden of reading stats
that are never used.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
2014-03-27 23:42:54 +04:00
|
|
|
if (likely(stats)) {
|
|
|
|
spin_lock(&stats->lock);
|
|
|
|
/* Mark if we write on the pre-allocated stats. */
|
2016-09-16 01:11:53 +03:00
|
|
|
if (cpu == 0 && unlikely(flow->stats_last_writer != cpu))
|
|
|
|
flow->stats_last_writer = cpu;
|
openvswitch: Per NUMA node flow stats.
Keep kernel flow stats for each NUMA node rather than each (logical)
CPU. This avoids using the per-CPU allocator and removes most of the
kernel-side OVS locking overhead otherwise on the top of perf reports
and allows OVS to scale better with higher number of threads.
With 9 handlers and 4 revalidators netperf TCP_CRR test flow setup
rate doubles on a server with two hyper-threaded physical CPUs (16
logical cores each) compared to the current OVS master. Tested with
non-trivial flow table with a TCP port match rule forcing all new
connections with unique port numbers to OVS userspace. The IP
addresses are still wildcarded, so the kernel flows are not considered
as exact match 5-tuple flows. This type of flows can be expected to
appear in large numbers as the result of more effective wildcarding
made possible by improvements in OVS userspace flow classifier.
Perf results for this test (master):
Events: 305K cycles
+ 8.43% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 5.64% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 4.75% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 3.32% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 2.61% ovs-vswitchd [kernel.kallsyms] [k] pcpu_alloc_area
+ 2.19% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.03% swapper [kernel.kallsyms] [k] intel_idle
+ 1.84% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 1.64% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.58% ovs-vswitchd libc-2.15.so [.] 0x7f4e6
+ 1.07% ovs-vswitchd [kernel.kallsyms] [k] memset
+ 1.03% netperf [kernel.kallsyms] [k] __ticket_spin_lock
+ 0.92% swapper [kernel.kallsyms] [k] __ticket_spin_lock
...
And after this patch:
Events: 356K cycles
+ 6.85% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 4.63% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 3.06% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 2.81% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.51% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 2.27% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.84% ovs-vswitchd libc-2.15.so [.] 0x15d30f
+ 1.74% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 1.47% swapper [kernel.kallsyms] [k] intel_idle
+ 1.34% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask
+ 1.33% ovs-vswitchd ovs-vswitchd [.] rule_actions_unref
+ 1.16% ovs-vswitchd ovs-vswitchd [.] hindex_node_with_hash
+ 1.16% ovs-vswitchd ovs-vswitchd [.] do_xlate_actions
+ 1.09% ovs-vswitchd ovs-vswitchd [.] ofproto_rule_ref
+ 1.01% netperf [kernel.kallsyms] [k] __ticket_spin_lock
...
There is a small increase in kernel spinlock overhead due to the same
spinlock being shared between multiple cores of the same physical CPU,
but that is barely visible in the netperf TCP_CRR test performance
(maybe ~1% performance drop, hard to tell exactly due to variance in
the test results), when testing for kernel module throughput (with no
userspace activity, handful of kernel flows).
On flow setup, a single stats instance is allocated (for the NUMA node
0). As CPUs from multiple NUMA nodes start updating stats, new
NUMA-node specific stats instances are allocated. This allocation on
the packet processing code path is made to never block or look for
emergency memory pools, minimizing the allocation latency. If the
allocation fails, the existing preallocated stats instance is used.
Also, if only CPUs from one NUMA-node are updating the preallocated
stats instance, no additional stats instances are allocated. This
eliminates the need to pre-allocate stats instances that will not be
used, also relieving the stats reader from the burden of reading stats
that are never used.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
2014-03-27 23:42:54 +04:00
|
|
|
} else {
|
|
|
|
stats = rcu_dereference(flow->stats[0]); /* Pre-allocated. */
|
|
|
|
spin_lock(&stats->lock);
|
|
|
|
|
2016-09-16 01:11:53 +03:00
|
|
|
/* If the current CPU is the only writer on the
|
openvswitch: Per NUMA node flow stats.
Keep kernel flow stats for each NUMA node rather than each (logical)
CPU. This avoids using the per-CPU allocator and removes most of the
kernel-side OVS locking overhead otherwise on the top of perf reports
and allows OVS to scale better with higher number of threads.
With 9 handlers and 4 revalidators netperf TCP_CRR test flow setup
rate doubles on a server with two hyper-threaded physical CPUs (16
logical cores each) compared to the current OVS master. Tested with
non-trivial flow table with a TCP port match rule forcing all new
connections with unique port numbers to OVS userspace. The IP
addresses are still wildcarded, so the kernel flows are not considered
as exact match 5-tuple flows. This type of flows can be expected to
appear in large numbers as the result of more effective wildcarding
made possible by improvements in OVS userspace flow classifier.
Perf results for this test (master):
Events: 305K cycles
+ 8.43% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 5.64% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 4.75% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 3.32% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 2.61% ovs-vswitchd [kernel.kallsyms] [k] pcpu_alloc_area
+ 2.19% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.03% swapper [kernel.kallsyms] [k] intel_idle
+ 1.84% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 1.64% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.58% ovs-vswitchd libc-2.15.so [.] 0x7f4e6
+ 1.07% ovs-vswitchd [kernel.kallsyms] [k] memset
+ 1.03% netperf [kernel.kallsyms] [k] __ticket_spin_lock
+ 0.92% swapper [kernel.kallsyms] [k] __ticket_spin_lock
...
And after this patch:
Events: 356K cycles
+ 6.85% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 4.63% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 3.06% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 2.81% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.51% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 2.27% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.84% ovs-vswitchd libc-2.15.so [.] 0x15d30f
+ 1.74% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 1.47% swapper [kernel.kallsyms] [k] intel_idle
+ 1.34% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask
+ 1.33% ovs-vswitchd ovs-vswitchd [.] rule_actions_unref
+ 1.16% ovs-vswitchd ovs-vswitchd [.] hindex_node_with_hash
+ 1.16% ovs-vswitchd ovs-vswitchd [.] do_xlate_actions
+ 1.09% ovs-vswitchd ovs-vswitchd [.] ofproto_rule_ref
+ 1.01% netperf [kernel.kallsyms] [k] __ticket_spin_lock
...
There is a small increase in kernel spinlock overhead due to the same
spinlock being shared between multiple cores of the same physical CPU,
but that is barely visible in the netperf TCP_CRR test performance
(maybe ~1% performance drop, hard to tell exactly due to variance in
the test results), when testing for kernel module throughput (with no
userspace activity, handful of kernel flows).
On flow setup, a single stats instance is allocated (for the NUMA node
0). As CPUs from multiple NUMA nodes start updating stats, new
NUMA-node specific stats instances are allocated. This allocation on
the packet processing code path is made to never block or look for
emergency memory pools, minimizing the allocation latency. If the
allocation fails, the existing preallocated stats instance is used.
Also, if only CPUs from one NUMA-node are updating the preallocated
stats instance, no additional stats instances are allocated. This
eliminates the need to pre-allocate stats instances that will not be
used, also relieving the stats reader from the burden of reading stats
that are never used.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
2014-03-27 23:42:54 +04:00
|
|
|
* pre-allocated stats keep using them.
|
|
|
|
*/
|
2016-09-16 01:11:53 +03:00
|
|
|
if (unlikely(flow->stats_last_writer != cpu)) {
|
openvswitch: Per NUMA node flow stats.
Keep kernel flow stats for each NUMA node rather than each (logical)
CPU. This avoids using the per-CPU allocator and removes most of the
kernel-side OVS locking overhead otherwise on the top of perf reports
and allows OVS to scale better with higher number of threads.
With 9 handlers and 4 revalidators netperf TCP_CRR test flow setup
rate doubles on a server with two hyper-threaded physical CPUs (16
logical cores each) compared to the current OVS master. Tested with
non-trivial flow table with a TCP port match rule forcing all new
connections with unique port numbers to OVS userspace. The IP
addresses are still wildcarded, so the kernel flows are not considered
as exact match 5-tuple flows. This type of flows can be expected to
appear in large numbers as the result of more effective wildcarding
made possible by improvements in OVS userspace flow classifier.
Perf results for this test (master):
Events: 305K cycles
+ 8.43% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 5.64% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 4.75% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 3.32% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 2.61% ovs-vswitchd [kernel.kallsyms] [k] pcpu_alloc_area
+ 2.19% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.03% swapper [kernel.kallsyms] [k] intel_idle
+ 1.84% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 1.64% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.58% ovs-vswitchd libc-2.15.so [.] 0x7f4e6
+ 1.07% ovs-vswitchd [kernel.kallsyms] [k] memset
+ 1.03% netperf [kernel.kallsyms] [k] __ticket_spin_lock
+ 0.92% swapper [kernel.kallsyms] [k] __ticket_spin_lock
...
And after this patch:
Events: 356K cycles
+ 6.85% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 4.63% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 3.06% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 2.81% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.51% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 2.27% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.84% ovs-vswitchd libc-2.15.so [.] 0x15d30f
+ 1.74% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 1.47% swapper [kernel.kallsyms] [k] intel_idle
+ 1.34% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask
+ 1.33% ovs-vswitchd ovs-vswitchd [.] rule_actions_unref
+ 1.16% ovs-vswitchd ovs-vswitchd [.] hindex_node_with_hash
+ 1.16% ovs-vswitchd ovs-vswitchd [.] do_xlate_actions
+ 1.09% ovs-vswitchd ovs-vswitchd [.] ofproto_rule_ref
+ 1.01% netperf [kernel.kallsyms] [k] __ticket_spin_lock
...
There is a small increase in kernel spinlock overhead due to the same
spinlock being shared between multiple cores of the same physical CPU,
but that is barely visible in the netperf TCP_CRR test performance
(maybe ~1% performance drop, hard to tell exactly due to variance in
the test results), when testing for kernel module throughput (with no
userspace activity, handful of kernel flows).
On flow setup, a single stats instance is allocated (for the NUMA node
0). As CPUs from multiple NUMA nodes start updating stats, new
NUMA-node specific stats instances are allocated. This allocation on
the packet processing code path is made to never block or look for
emergency memory pools, minimizing the allocation latency. If the
allocation fails, the existing preallocated stats instance is used.
Also, if only CPUs from one NUMA-node are updating the preallocated
stats instance, no additional stats instances are allocated. This
eliminates the need to pre-allocate stats instances that will not be
used, also relieving the stats reader from the burden of reading stats
that are never used.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
2014-03-27 23:42:54 +04:00
|
|
|
/* A previous locker may have already allocated the
|
2016-09-16 01:11:53 +03:00
|
|
|
* stats, so we need to check again. If CPU-specific
|
openvswitch: Per NUMA node flow stats.
Keep kernel flow stats for each NUMA node rather than each (logical)
CPU. This avoids using the per-CPU allocator and removes most of the
kernel-side OVS locking overhead otherwise on the top of perf reports
and allows OVS to scale better with higher number of threads.
With 9 handlers and 4 revalidators netperf TCP_CRR test flow setup
rate doubles on a server with two hyper-threaded physical CPUs (16
logical cores each) compared to the current OVS master. Tested with
non-trivial flow table with a TCP port match rule forcing all new
connections with unique port numbers to OVS userspace. The IP
addresses are still wildcarded, so the kernel flows are not considered
as exact match 5-tuple flows. This type of flows can be expected to
appear in large numbers as the result of more effective wildcarding
made possible by improvements in OVS userspace flow classifier.
Perf results for this test (master):
Events: 305K cycles
+ 8.43% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 5.64% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 4.75% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 3.32% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 2.61% ovs-vswitchd [kernel.kallsyms] [k] pcpu_alloc_area
+ 2.19% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.03% swapper [kernel.kallsyms] [k] intel_idle
+ 1.84% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 1.64% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.58% ovs-vswitchd libc-2.15.so [.] 0x7f4e6
+ 1.07% ovs-vswitchd [kernel.kallsyms] [k] memset
+ 1.03% netperf [kernel.kallsyms] [k] __ticket_spin_lock
+ 0.92% swapper [kernel.kallsyms] [k] __ticket_spin_lock
...
And after this patch:
Events: 356K cycles
+ 6.85% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 4.63% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 3.06% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 2.81% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.51% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 2.27% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.84% ovs-vswitchd libc-2.15.so [.] 0x15d30f
+ 1.74% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 1.47% swapper [kernel.kallsyms] [k] intel_idle
+ 1.34% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask
+ 1.33% ovs-vswitchd ovs-vswitchd [.] rule_actions_unref
+ 1.16% ovs-vswitchd ovs-vswitchd [.] hindex_node_with_hash
+ 1.16% ovs-vswitchd ovs-vswitchd [.] do_xlate_actions
+ 1.09% ovs-vswitchd ovs-vswitchd [.] ofproto_rule_ref
+ 1.01% netperf [kernel.kallsyms] [k] __ticket_spin_lock
...
There is a small increase in kernel spinlock overhead due to the same
spinlock being shared between multiple cores of the same physical CPU,
but that is barely visible in the netperf TCP_CRR test performance
(maybe ~1% performance drop, hard to tell exactly due to variance in
the test results), when testing for kernel module throughput (with no
userspace activity, handful of kernel flows).
On flow setup, a single stats instance is allocated (for the NUMA node
0). As CPUs from multiple NUMA nodes start updating stats, new
NUMA-node specific stats instances are allocated. This allocation on
the packet processing code path is made to never block or look for
emergency memory pools, minimizing the allocation latency. If the
allocation fails, the existing preallocated stats instance is used.
Also, if only CPUs from one NUMA-node are updating the preallocated
stats instance, no additional stats instances are allocated. This
eliminates the need to pre-allocate stats instances that will not be
used, also relieving the stats reader from the burden of reading stats
that are never used.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
2014-03-27 23:42:54 +04:00
|
|
|
* stats were already allocated, we update the pre-
|
|
|
|
* allocated stats as we have already locked them.
|
|
|
|
*/
|
2016-09-16 01:11:53 +03:00
|
|
|
if (likely(flow->stats_last_writer != -1) &&
|
|
|
|
likely(!rcu_access_pointer(flow->stats[cpu]))) {
|
|
|
|
/* Try to allocate CPU-specific stats. */
|
2019-07-19 19:20:13 +03:00
|
|
|
struct sw_flow_stats *new_stats;
|
openvswitch: Per NUMA node flow stats.
Keep kernel flow stats for each NUMA node rather than each (logical)
CPU. This avoids using the per-CPU allocator and removes most of the
kernel-side OVS locking overhead otherwise on the top of perf reports
and allows OVS to scale better with higher number of threads.
With 9 handlers and 4 revalidators netperf TCP_CRR test flow setup
rate doubles on a server with two hyper-threaded physical CPUs (16
logical cores each) compared to the current OVS master. Tested with
non-trivial flow table with a TCP port match rule forcing all new
connections with unique port numbers to OVS userspace. The IP
addresses are still wildcarded, so the kernel flows are not considered
as exact match 5-tuple flows. This type of flows can be expected to
appear in large numbers as the result of more effective wildcarding
made possible by improvements in OVS userspace flow classifier.
Perf results for this test (master):
Events: 305K cycles
+ 8.43% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 5.64% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 4.75% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 3.32% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 2.61% ovs-vswitchd [kernel.kallsyms] [k] pcpu_alloc_area
+ 2.19% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.03% swapper [kernel.kallsyms] [k] intel_idle
+ 1.84% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 1.64% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.58% ovs-vswitchd libc-2.15.so [.] 0x7f4e6
+ 1.07% ovs-vswitchd [kernel.kallsyms] [k] memset
+ 1.03% netperf [kernel.kallsyms] [k] __ticket_spin_lock
+ 0.92% swapper [kernel.kallsyms] [k] __ticket_spin_lock
...
And after this patch:
Events: 356K cycles
+ 6.85% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 4.63% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 3.06% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 2.81% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.51% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 2.27% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.84% ovs-vswitchd libc-2.15.so [.] 0x15d30f
+ 1.74% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 1.47% swapper [kernel.kallsyms] [k] intel_idle
+ 1.34% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask
+ 1.33% ovs-vswitchd ovs-vswitchd [.] rule_actions_unref
+ 1.16% ovs-vswitchd ovs-vswitchd [.] hindex_node_with_hash
+ 1.16% ovs-vswitchd ovs-vswitchd [.] do_xlate_actions
+ 1.09% ovs-vswitchd ovs-vswitchd [.] ofproto_rule_ref
+ 1.01% netperf [kernel.kallsyms] [k] __ticket_spin_lock
...
There is a small increase in kernel spinlock overhead due to the same
spinlock being shared between multiple cores of the same physical CPU,
but that is barely visible in the netperf TCP_CRR test performance
(maybe ~1% performance drop, hard to tell exactly due to variance in
the test results), when testing for kernel module throughput (with no
userspace activity, handful of kernel flows).
On flow setup, a single stats instance is allocated (for the NUMA node
0). As CPUs from multiple NUMA nodes start updating stats, new
NUMA-node specific stats instances are allocated. This allocation on
the packet processing code path is made to never block or look for
emergency memory pools, minimizing the allocation latency. If the
allocation fails, the existing preallocated stats instance is used.
Also, if only CPUs from one NUMA-node are updating the preallocated
stats instance, no additional stats instances are allocated. This
eliminates the need to pre-allocate stats instances that will not be
used, also relieving the stats reader from the burden of reading stats
that are never used.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
2014-03-27 23:42:54 +04:00
|
|
|
|
|
|
|
new_stats =
|
|
|
|
kmem_cache_alloc_node(flow_stats_cache,
|
mm: remove GFP_THISNODE
NOTE: this is not about __GFP_THISNODE, this is only about GFP_THISNODE.
GFP_THISNODE is a secret combination of gfp bits that have different
behavior than expected. It is a combination of __GFP_THISNODE,
__GFP_NORETRY, and __GFP_NOWARN and is special-cased in the page
allocator slowpath to fail without trying reclaim even though it may be
used in combination with __GFP_WAIT.
An example of the problem this creates: commit e97ca8e5b864 ("mm: fix
GFP_THISNODE callers and clarify") fixed up many users of GFP_THISNODE
that really just wanted __GFP_THISNODE. The problem doesn't end there,
however, because even it was a no-op for alloc_misplaced_dst_page(),
which also sets __GFP_NORETRY and __GFP_NOWARN, and
migrate_misplaced_transhuge_page(), where __GFP_NORETRY and __GFP_NOWAIT
is set in GFP_TRANSHUGE. Converting GFP_THISNODE to __GFP_THISNODE is a
no-op in these cases since the page allocator special-cases
__GFP_THISNODE && __GFP_NORETRY && __GFP_NOWARN.
It's time to just remove GFP_THISNODE entirely. We leave __GFP_THISNODE
to restrict an allocation to a local node, but remove GFP_THISNODE and
its obscurity. Instead, we require that a caller clear __GFP_WAIT if it
wants to avoid reclaim.
This allows the aforementioned functions to actually reclaim as they
should. It also enables any future callers that want to do
__GFP_THISNODE but also __GFP_NORETRY && __GFP_NOWARN to reclaim. The
rule is simple: if you don't want to reclaim, then don't set __GFP_WAIT.
Aside: ovs_flow_stats_update() really wants to avoid reclaim as well, so
it is unchanged.
Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Christoph Lameter <cl@linux.com>
Acked-by: Pekka Enberg <penberg@kernel.org>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Pravin Shelar <pshelar@nicira.com>
Cc: Jarno Rajahalme <jrajahalme@nicira.com>
Cc: Li Zefan <lizefan@huawei.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-15 01:46:55 +03:00
|
|
|
GFP_NOWAIT |
|
|
|
|
__GFP_THISNODE |
|
|
|
|
__GFP_NOWARN |
|
openvswitch: Per NUMA node flow stats.
Keep kernel flow stats for each NUMA node rather than each (logical)
CPU. This avoids using the per-CPU allocator and removes most of the
kernel-side OVS locking overhead otherwise on the top of perf reports
and allows OVS to scale better with higher number of threads.
With 9 handlers and 4 revalidators netperf TCP_CRR test flow setup
rate doubles on a server with two hyper-threaded physical CPUs (16
logical cores each) compared to the current OVS master. Tested with
non-trivial flow table with a TCP port match rule forcing all new
connections with unique port numbers to OVS userspace. The IP
addresses are still wildcarded, so the kernel flows are not considered
as exact match 5-tuple flows. This type of flows can be expected to
appear in large numbers as the result of more effective wildcarding
made possible by improvements in OVS userspace flow classifier.
Perf results for this test (master):
Events: 305K cycles
+ 8.43% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 5.64% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 4.75% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 3.32% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 2.61% ovs-vswitchd [kernel.kallsyms] [k] pcpu_alloc_area
+ 2.19% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.03% swapper [kernel.kallsyms] [k] intel_idle
+ 1.84% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 1.64% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.58% ovs-vswitchd libc-2.15.so [.] 0x7f4e6
+ 1.07% ovs-vswitchd [kernel.kallsyms] [k] memset
+ 1.03% netperf [kernel.kallsyms] [k] __ticket_spin_lock
+ 0.92% swapper [kernel.kallsyms] [k] __ticket_spin_lock
...
And after this patch:
Events: 356K cycles
+ 6.85% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 4.63% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 3.06% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 2.81% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.51% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 2.27% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.84% ovs-vswitchd libc-2.15.so [.] 0x15d30f
+ 1.74% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 1.47% swapper [kernel.kallsyms] [k] intel_idle
+ 1.34% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask
+ 1.33% ovs-vswitchd ovs-vswitchd [.] rule_actions_unref
+ 1.16% ovs-vswitchd ovs-vswitchd [.] hindex_node_with_hash
+ 1.16% ovs-vswitchd ovs-vswitchd [.] do_xlate_actions
+ 1.09% ovs-vswitchd ovs-vswitchd [.] ofproto_rule_ref
+ 1.01% netperf [kernel.kallsyms] [k] __ticket_spin_lock
...
There is a small increase in kernel spinlock overhead due to the same
spinlock being shared between multiple cores of the same physical CPU,
but that is barely visible in the netperf TCP_CRR test performance
(maybe ~1% performance drop, hard to tell exactly due to variance in
the test results), when testing for kernel module throughput (with no
userspace activity, handful of kernel flows).
On flow setup, a single stats instance is allocated (for the NUMA node
0). As CPUs from multiple NUMA nodes start updating stats, new
NUMA-node specific stats instances are allocated. This allocation on
the packet processing code path is made to never block or look for
emergency memory pools, minimizing the allocation latency. If the
allocation fails, the existing preallocated stats instance is used.
Also, if only CPUs from one NUMA-node are updating the preallocated
stats instance, no additional stats instances are allocated. This
eliminates the need to pre-allocate stats instances that will not be
used, also relieving the stats reader from the burden of reading stats
that are never used.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
2014-03-27 23:42:54 +04:00
|
|
|
__GFP_NOMEMALLOC,
|
2017-07-18 09:28:05 +03:00
|
|
|
numa_node_id());
|
openvswitch: Per NUMA node flow stats.
Keep kernel flow stats for each NUMA node rather than each (logical)
CPU. This avoids using the per-CPU allocator and removes most of the
kernel-side OVS locking overhead otherwise on the top of perf reports
and allows OVS to scale better with higher number of threads.
With 9 handlers and 4 revalidators netperf TCP_CRR test flow setup
rate doubles on a server with two hyper-threaded physical CPUs (16
logical cores each) compared to the current OVS master. Tested with
non-trivial flow table with a TCP port match rule forcing all new
connections with unique port numbers to OVS userspace. The IP
addresses are still wildcarded, so the kernel flows are not considered
as exact match 5-tuple flows. This type of flows can be expected to
appear in large numbers as the result of more effective wildcarding
made possible by improvements in OVS userspace flow classifier.
Perf results for this test (master):
Events: 305K cycles
+ 8.43% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 5.64% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 4.75% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 3.32% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 2.61% ovs-vswitchd [kernel.kallsyms] [k] pcpu_alloc_area
+ 2.19% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.03% swapper [kernel.kallsyms] [k] intel_idle
+ 1.84% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 1.64% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.58% ovs-vswitchd libc-2.15.so [.] 0x7f4e6
+ 1.07% ovs-vswitchd [kernel.kallsyms] [k] memset
+ 1.03% netperf [kernel.kallsyms] [k] __ticket_spin_lock
+ 0.92% swapper [kernel.kallsyms] [k] __ticket_spin_lock
...
And after this patch:
Events: 356K cycles
+ 6.85% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 4.63% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 3.06% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 2.81% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.51% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 2.27% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.84% ovs-vswitchd libc-2.15.so [.] 0x15d30f
+ 1.74% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 1.47% swapper [kernel.kallsyms] [k] intel_idle
+ 1.34% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask
+ 1.33% ovs-vswitchd ovs-vswitchd [.] rule_actions_unref
+ 1.16% ovs-vswitchd ovs-vswitchd [.] hindex_node_with_hash
+ 1.16% ovs-vswitchd ovs-vswitchd [.] do_xlate_actions
+ 1.09% ovs-vswitchd ovs-vswitchd [.] ofproto_rule_ref
+ 1.01% netperf [kernel.kallsyms] [k] __ticket_spin_lock
...
There is a small increase in kernel spinlock overhead due to the same
spinlock being shared between multiple cores of the same physical CPU,
but that is barely visible in the netperf TCP_CRR test performance
(maybe ~1% performance drop, hard to tell exactly due to variance in
the test results), when testing for kernel module throughput (with no
userspace activity, handful of kernel flows).
On flow setup, a single stats instance is allocated (for the NUMA node
0). As CPUs from multiple NUMA nodes start updating stats, new
NUMA-node specific stats instances are allocated. This allocation on
the packet processing code path is made to never block or look for
emergency memory pools, minimizing the allocation latency. If the
allocation fails, the existing preallocated stats instance is used.
Also, if only CPUs from one NUMA-node are updating the preallocated
stats instance, no additional stats instances are allocated. This
eliminates the need to pre-allocate stats instances that will not be
used, also relieving the stats reader from the burden of reading stats
that are never used.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
2014-03-27 23:42:54 +04:00
|
|
|
if (likely(new_stats)) {
|
|
|
|
new_stats->used = jiffies;
|
|
|
|
new_stats->packet_count = 1;
|
2014-12-31 19:45:46 +03:00
|
|
|
new_stats->byte_count = len;
|
openvswitch: Per NUMA node flow stats.
Keep kernel flow stats for each NUMA node rather than each (logical)
CPU. This avoids using the per-CPU allocator and removes most of the
kernel-side OVS locking overhead otherwise on the top of perf reports
and allows OVS to scale better with higher number of threads.
With 9 handlers and 4 revalidators netperf TCP_CRR test flow setup
rate doubles on a server with two hyper-threaded physical CPUs (16
logical cores each) compared to the current OVS master. Tested with
non-trivial flow table with a TCP port match rule forcing all new
connections with unique port numbers to OVS userspace. The IP
addresses are still wildcarded, so the kernel flows are not considered
as exact match 5-tuple flows. This type of flows can be expected to
appear in large numbers as the result of more effective wildcarding
made possible by improvements in OVS userspace flow classifier.
Perf results for this test (master):
Events: 305K cycles
+ 8.43% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 5.64% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 4.75% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 3.32% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 2.61% ovs-vswitchd [kernel.kallsyms] [k] pcpu_alloc_area
+ 2.19% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.03% swapper [kernel.kallsyms] [k] intel_idle
+ 1.84% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 1.64% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.58% ovs-vswitchd libc-2.15.so [.] 0x7f4e6
+ 1.07% ovs-vswitchd [kernel.kallsyms] [k] memset
+ 1.03% netperf [kernel.kallsyms] [k] __ticket_spin_lock
+ 0.92% swapper [kernel.kallsyms] [k] __ticket_spin_lock
...
And after this patch:
Events: 356K cycles
+ 6.85% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 4.63% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 3.06% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 2.81% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.51% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 2.27% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.84% ovs-vswitchd libc-2.15.so [.] 0x15d30f
+ 1.74% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 1.47% swapper [kernel.kallsyms] [k] intel_idle
+ 1.34% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask
+ 1.33% ovs-vswitchd ovs-vswitchd [.] rule_actions_unref
+ 1.16% ovs-vswitchd ovs-vswitchd [.] hindex_node_with_hash
+ 1.16% ovs-vswitchd ovs-vswitchd [.] do_xlate_actions
+ 1.09% ovs-vswitchd ovs-vswitchd [.] ofproto_rule_ref
+ 1.01% netperf [kernel.kallsyms] [k] __ticket_spin_lock
...
There is a small increase in kernel spinlock overhead due to the same
spinlock being shared between multiple cores of the same physical CPU,
but that is barely visible in the netperf TCP_CRR test performance
(maybe ~1% performance drop, hard to tell exactly due to variance in
the test results), when testing for kernel module throughput (with no
userspace activity, handful of kernel flows).
On flow setup, a single stats instance is allocated (for the NUMA node
0). As CPUs from multiple NUMA nodes start updating stats, new
NUMA-node specific stats instances are allocated. This allocation on
the packet processing code path is made to never block or look for
emergency memory pools, minimizing the allocation latency. If the
allocation fails, the existing preallocated stats instance is used.
Also, if only CPUs from one NUMA-node are updating the preallocated
stats instance, no additional stats instances are allocated. This
eliminates the need to pre-allocate stats instances that will not be
used, also relieving the stats reader from the burden of reading stats
that are never used.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
2014-03-27 23:42:54 +04:00
|
|
|
new_stats->tcp_flags = tcp_flags;
|
|
|
|
spin_lock_init(&new_stats->lock);
|
|
|
|
|
2016-09-16 01:11:53 +03:00
|
|
|
rcu_assign_pointer(flow->stats[cpu],
|
openvswitch: Per NUMA node flow stats.
Keep kernel flow stats for each NUMA node rather than each (logical)
CPU. This avoids using the per-CPU allocator and removes most of the
kernel-side OVS locking overhead otherwise on the top of perf reports
and allows OVS to scale better with higher number of threads.
With 9 handlers and 4 revalidators netperf TCP_CRR test flow setup
rate doubles on a server with two hyper-threaded physical CPUs (16
logical cores each) compared to the current OVS master. Tested with
non-trivial flow table with a TCP port match rule forcing all new
connections with unique port numbers to OVS userspace. The IP
addresses are still wildcarded, so the kernel flows are not considered
as exact match 5-tuple flows. This type of flows can be expected to
appear in large numbers as the result of more effective wildcarding
made possible by improvements in OVS userspace flow classifier.
Perf results for this test (master):
Events: 305K cycles
+ 8.43% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 5.64% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 4.75% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 3.32% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 2.61% ovs-vswitchd [kernel.kallsyms] [k] pcpu_alloc_area
+ 2.19% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.03% swapper [kernel.kallsyms] [k] intel_idle
+ 1.84% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 1.64% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.58% ovs-vswitchd libc-2.15.so [.] 0x7f4e6
+ 1.07% ovs-vswitchd [kernel.kallsyms] [k] memset
+ 1.03% netperf [kernel.kallsyms] [k] __ticket_spin_lock
+ 0.92% swapper [kernel.kallsyms] [k] __ticket_spin_lock
...
And after this patch:
Events: 356K cycles
+ 6.85% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 4.63% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 3.06% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 2.81% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.51% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 2.27% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.84% ovs-vswitchd libc-2.15.so [.] 0x15d30f
+ 1.74% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 1.47% swapper [kernel.kallsyms] [k] intel_idle
+ 1.34% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask
+ 1.33% ovs-vswitchd ovs-vswitchd [.] rule_actions_unref
+ 1.16% ovs-vswitchd ovs-vswitchd [.] hindex_node_with_hash
+ 1.16% ovs-vswitchd ovs-vswitchd [.] do_xlate_actions
+ 1.09% ovs-vswitchd ovs-vswitchd [.] ofproto_rule_ref
+ 1.01% netperf [kernel.kallsyms] [k] __ticket_spin_lock
...
There is a small increase in kernel spinlock overhead due to the same
spinlock being shared between multiple cores of the same physical CPU,
but that is barely visible in the netperf TCP_CRR test performance
(maybe ~1% performance drop, hard to tell exactly due to variance in
the test results), when testing for kernel module throughput (with no
userspace activity, handful of kernel flows).
On flow setup, a single stats instance is allocated (for the NUMA node
0). As CPUs from multiple NUMA nodes start updating stats, new
NUMA-node specific stats instances are allocated. This allocation on
the packet processing code path is made to never block or look for
emergency memory pools, minimizing the allocation latency. If the
allocation fails, the existing preallocated stats instance is used.
Also, if only CPUs from one NUMA-node are updating the preallocated
stats instance, no additional stats instances are allocated. This
eliminates the need to pre-allocate stats instances that will not be
used, also relieving the stats reader from the burden of reading stats
that are never used.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
2014-03-27 23:42:54 +04:00
|
|
|
new_stats);
|
openvswitch: Optimize operations for OvS flow_stats.
When calling the flow_free() to free the flow, we call many times
(cpu_possible_mask, eg. 128 as default) cpumask_next(). That will
take up our CPU usage if we call the flow_free() frequently.
When we put all packets to userspace via upcall, and OvS will send
them back via netlink to ovs_packet_cmd_execute(will call flow_free).
The test topo is shown as below. VM01 sends TCP packets to VM02,
and OvS forward packtets. When testing, we use perf to report the
system performance.
VM01 --- OvS-VM --- VM02
Without this patch, perf-top show as below: The flow_free() is
3.02% CPU usage.
4.23% [kernel] [k] _raw_spin_unlock_irqrestore
3.62% [kernel] [k] __do_softirq
3.16% [kernel] [k] __memcpy
3.02% [kernel] [k] flow_free
2.42% libc-2.17.so [.] __memcpy_ssse3_back
2.18% [kernel] [k] copy_user_generic_unrolled
2.17% [kernel] [k] find_next_bit
When applied this patch, perf-top show as below: Not shown on
the list anymore.
4.11% [kernel] [k] _raw_spin_unlock_irqrestore
3.79% [kernel] [k] __do_softirq
3.46% [kernel] [k] __memcpy
2.73% libc-2.17.so [.] __memcpy_ssse3_back
2.25% [kernel] [k] copy_user_generic_unrolled
1.89% libc-2.17.so [.] _int_malloc
1.53% ovs-vswitchd [.] xlate_actions
With this patch, the TCP throughput(we dont use Megaflow Cache
+ Microflow Cache) between VMs is 1.18Gbs/sec up to 1.30Gbs/sec
(maybe ~10% performance imporve).
This patch adds cpumask struct, the cpu_used_mask stores the cpu_id
that the flow used. And we only check the flow_stats on the cpu we
used, and it is unncessary to check all possible cpu when getting,
cleaning, and updating the flow_stats. Adding the cpu_used_mask to
sw_flow struct does’t increase the cacheline number.
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-18 09:28:06 +03:00
|
|
|
cpumask_set_cpu(cpu, &flow->cpu_used_mask);
|
openvswitch: Per NUMA node flow stats.
Keep kernel flow stats for each NUMA node rather than each (logical)
CPU. This avoids using the per-CPU allocator and removes most of the
kernel-side OVS locking overhead otherwise on the top of perf reports
and allows OVS to scale better with higher number of threads.
With 9 handlers and 4 revalidators netperf TCP_CRR test flow setup
rate doubles on a server with two hyper-threaded physical CPUs (16
logical cores each) compared to the current OVS master. Tested with
non-trivial flow table with a TCP port match rule forcing all new
connections with unique port numbers to OVS userspace. The IP
addresses are still wildcarded, so the kernel flows are not considered
as exact match 5-tuple flows. This type of flows can be expected to
appear in large numbers as the result of more effective wildcarding
made possible by improvements in OVS userspace flow classifier.
Perf results for this test (master):
Events: 305K cycles
+ 8.43% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 5.64% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 4.75% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 3.32% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 2.61% ovs-vswitchd [kernel.kallsyms] [k] pcpu_alloc_area
+ 2.19% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.03% swapper [kernel.kallsyms] [k] intel_idle
+ 1.84% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 1.64% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.58% ovs-vswitchd libc-2.15.so [.] 0x7f4e6
+ 1.07% ovs-vswitchd [kernel.kallsyms] [k] memset
+ 1.03% netperf [kernel.kallsyms] [k] __ticket_spin_lock
+ 0.92% swapper [kernel.kallsyms] [k] __ticket_spin_lock
...
And after this patch:
Events: 356K cycles
+ 6.85% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 4.63% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 3.06% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 2.81% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.51% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 2.27% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.84% ovs-vswitchd libc-2.15.so [.] 0x15d30f
+ 1.74% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 1.47% swapper [kernel.kallsyms] [k] intel_idle
+ 1.34% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask
+ 1.33% ovs-vswitchd ovs-vswitchd [.] rule_actions_unref
+ 1.16% ovs-vswitchd ovs-vswitchd [.] hindex_node_with_hash
+ 1.16% ovs-vswitchd ovs-vswitchd [.] do_xlate_actions
+ 1.09% ovs-vswitchd ovs-vswitchd [.] ofproto_rule_ref
+ 1.01% netperf [kernel.kallsyms] [k] __ticket_spin_lock
...
There is a small increase in kernel spinlock overhead due to the same
spinlock being shared between multiple cores of the same physical CPU,
but that is barely visible in the netperf TCP_CRR test performance
(maybe ~1% performance drop, hard to tell exactly due to variance in
the test results), when testing for kernel module throughput (with no
userspace activity, handful of kernel flows).
On flow setup, a single stats instance is allocated (for the NUMA node
0). As CPUs from multiple NUMA nodes start updating stats, new
NUMA-node specific stats instances are allocated. This allocation on
the packet processing code path is made to never block or look for
emergency memory pools, minimizing the allocation latency. If the
allocation fails, the existing preallocated stats instance is used.
Also, if only CPUs from one NUMA-node are updating the preallocated
stats instance, no additional stats instances are allocated. This
eliminates the need to pre-allocate stats instances that will not be
used, also relieving the stats reader from the burden of reading stats
that are never used.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
2014-03-27 23:42:54 +04:00
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
}
|
2016-09-16 01:11:53 +03:00
|
|
|
flow->stats_last_writer = cpu;
|
openvswitch: Per NUMA node flow stats.
Keep kernel flow stats for each NUMA node rather than each (logical)
CPU. This avoids using the per-CPU allocator and removes most of the
kernel-side OVS locking overhead otherwise on the top of perf reports
and allows OVS to scale better with higher number of threads.
With 9 handlers and 4 revalidators netperf TCP_CRR test flow setup
rate doubles on a server with two hyper-threaded physical CPUs (16
logical cores each) compared to the current OVS master. Tested with
non-trivial flow table with a TCP port match rule forcing all new
connections with unique port numbers to OVS userspace. The IP
addresses are still wildcarded, so the kernel flows are not considered
as exact match 5-tuple flows. This type of flows can be expected to
appear in large numbers as the result of more effective wildcarding
made possible by improvements in OVS userspace flow classifier.
Perf results for this test (master):
Events: 305K cycles
+ 8.43% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 5.64% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 4.75% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 3.32% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 2.61% ovs-vswitchd [kernel.kallsyms] [k] pcpu_alloc_area
+ 2.19% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.03% swapper [kernel.kallsyms] [k] intel_idle
+ 1.84% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 1.64% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.58% ovs-vswitchd libc-2.15.so [.] 0x7f4e6
+ 1.07% ovs-vswitchd [kernel.kallsyms] [k] memset
+ 1.03% netperf [kernel.kallsyms] [k] __ticket_spin_lock
+ 0.92% swapper [kernel.kallsyms] [k] __ticket_spin_lock
...
And after this patch:
Events: 356K cycles
+ 6.85% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 4.63% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 3.06% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 2.81% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.51% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 2.27% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.84% ovs-vswitchd libc-2.15.so [.] 0x15d30f
+ 1.74% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 1.47% swapper [kernel.kallsyms] [k] intel_idle
+ 1.34% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask
+ 1.33% ovs-vswitchd ovs-vswitchd [.] rule_actions_unref
+ 1.16% ovs-vswitchd ovs-vswitchd [.] hindex_node_with_hash
+ 1.16% ovs-vswitchd ovs-vswitchd [.] do_xlate_actions
+ 1.09% ovs-vswitchd ovs-vswitchd [.] ofproto_rule_ref
+ 1.01% netperf [kernel.kallsyms] [k] __ticket_spin_lock
...
There is a small increase in kernel spinlock overhead due to the same
spinlock being shared between multiple cores of the same physical CPU,
but that is barely visible in the netperf TCP_CRR test performance
(maybe ~1% performance drop, hard to tell exactly due to variance in
the test results), when testing for kernel module throughput (with no
userspace activity, handful of kernel flows).
On flow setup, a single stats instance is allocated (for the NUMA node
0). As CPUs from multiple NUMA nodes start updating stats, new
NUMA-node specific stats instances are allocated. This allocation on
the packet processing code path is made to never block or look for
emergency memory pools, minimizing the allocation latency. If the
allocation fails, the existing preallocated stats instance is used.
Also, if only CPUs from one NUMA-node are updating the preallocated
stats instance, no additional stats instances are allocated. This
eliminates the need to pre-allocate stats instances that will not be
used, also relieving the stats reader from the burden of reading stats
that are never used.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
2014-03-27 23:42:54 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-10-30 04:22:21 +04:00
|
|
|
stats->used = jiffies;
|
|
|
|
stats->packet_count++;
|
2014-12-31 19:45:46 +03:00
|
|
|
stats->byte_count += len;
|
2013-10-30 04:22:21 +04:00
|
|
|
stats->tcp_flags |= tcp_flags;
|
openvswitch: Per NUMA node flow stats.
Keep kernel flow stats for each NUMA node rather than each (logical)
CPU. This avoids using the per-CPU allocator and removes most of the
kernel-side OVS locking overhead otherwise on the top of perf reports
and allows OVS to scale better with higher number of threads.
With 9 handlers and 4 revalidators netperf TCP_CRR test flow setup
rate doubles on a server with two hyper-threaded physical CPUs (16
logical cores each) compared to the current OVS master. Tested with
non-trivial flow table with a TCP port match rule forcing all new
connections with unique port numbers to OVS userspace. The IP
addresses are still wildcarded, so the kernel flows are not considered
as exact match 5-tuple flows. This type of flows can be expected to
appear in large numbers as the result of more effective wildcarding
made possible by improvements in OVS userspace flow classifier.
Perf results for this test (master):
Events: 305K cycles
+ 8.43% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 5.64% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 4.75% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 3.32% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 2.61% ovs-vswitchd [kernel.kallsyms] [k] pcpu_alloc_area
+ 2.19% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.03% swapper [kernel.kallsyms] [k] intel_idle
+ 1.84% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 1.64% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.58% ovs-vswitchd libc-2.15.so [.] 0x7f4e6
+ 1.07% ovs-vswitchd [kernel.kallsyms] [k] memset
+ 1.03% netperf [kernel.kallsyms] [k] __ticket_spin_lock
+ 0.92% swapper [kernel.kallsyms] [k] __ticket_spin_lock
...
And after this patch:
Events: 356K cycles
+ 6.85% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 4.63% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 3.06% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 2.81% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.51% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 2.27% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.84% ovs-vswitchd libc-2.15.so [.] 0x15d30f
+ 1.74% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 1.47% swapper [kernel.kallsyms] [k] intel_idle
+ 1.34% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask
+ 1.33% ovs-vswitchd ovs-vswitchd [.] rule_actions_unref
+ 1.16% ovs-vswitchd ovs-vswitchd [.] hindex_node_with_hash
+ 1.16% ovs-vswitchd ovs-vswitchd [.] do_xlate_actions
+ 1.09% ovs-vswitchd ovs-vswitchd [.] ofproto_rule_ref
+ 1.01% netperf [kernel.kallsyms] [k] __ticket_spin_lock
...
There is a small increase in kernel spinlock overhead due to the same
spinlock being shared between multiple cores of the same physical CPU,
but that is barely visible in the netperf TCP_CRR test performance
(maybe ~1% performance drop, hard to tell exactly due to variance in
the test results), when testing for kernel module throughput (with no
userspace activity, handful of kernel flows).
On flow setup, a single stats instance is allocated (for the NUMA node
0). As CPUs from multiple NUMA nodes start updating stats, new
NUMA-node specific stats instances are allocated. This allocation on
the packet processing code path is made to never block or look for
emergency memory pools, minimizing the allocation latency. If the
allocation fails, the existing preallocated stats instance is used.
Also, if only CPUs from one NUMA-node are updating the preallocated
stats instance, no additional stats instances are allocated. This
eliminates the need to pre-allocate stats instances that will not be
used, also relieving the stats reader from the burden of reading stats
that are never used.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
2014-03-27 23:42:54 +04:00
|
|
|
unlock:
|
2013-10-30 04:22:21 +04:00
|
|
|
spin_unlock(&stats->lock);
|
|
|
|
}
|
|
|
|
|
2014-05-06 01:17:28 +04:00
|
|
|
/* Must be called with rcu_read_lock or ovs_mutex. */
|
|
|
|
void ovs_flow_stats_get(const struct sw_flow *flow,
|
|
|
|
struct ovs_flow_stats *ovs_stats,
|
2013-10-30 04:22:21 +04:00
|
|
|
unsigned long *used, __be16 *tcp_flags)
|
|
|
|
{
|
2016-09-16 01:11:53 +03:00
|
|
|
int cpu;
|
2013-10-30 04:22:21 +04:00
|
|
|
|
|
|
|
*used = 0;
|
|
|
|
*tcp_flags = 0;
|
|
|
|
memset(ovs_stats, 0, sizeof(*ovs_stats));
|
|
|
|
|
2016-09-16 01:11:53 +03:00
|
|
|
/* We open code this to make sure cpu 0 is always considered */
|
openvswitch: Optimize operations for OvS flow_stats.
When calling the flow_free() to free the flow, we call many times
(cpu_possible_mask, eg. 128 as default) cpumask_next(). That will
take up our CPU usage if we call the flow_free() frequently.
When we put all packets to userspace via upcall, and OvS will send
them back via netlink to ovs_packet_cmd_execute(will call flow_free).
The test topo is shown as below. VM01 sends TCP packets to VM02,
and OvS forward packtets. When testing, we use perf to report the
system performance.
VM01 --- OvS-VM --- VM02
Without this patch, perf-top show as below: The flow_free() is
3.02% CPU usage.
4.23% [kernel] [k] _raw_spin_unlock_irqrestore
3.62% [kernel] [k] __do_softirq
3.16% [kernel] [k] __memcpy
3.02% [kernel] [k] flow_free
2.42% libc-2.17.so [.] __memcpy_ssse3_back
2.18% [kernel] [k] copy_user_generic_unrolled
2.17% [kernel] [k] find_next_bit
When applied this patch, perf-top show as below: Not shown on
the list anymore.
4.11% [kernel] [k] _raw_spin_unlock_irqrestore
3.79% [kernel] [k] __do_softirq
3.46% [kernel] [k] __memcpy
2.73% libc-2.17.so [.] __memcpy_ssse3_back
2.25% [kernel] [k] copy_user_generic_unrolled
1.89% libc-2.17.so [.] _int_malloc
1.53% ovs-vswitchd [.] xlate_actions
With this patch, the TCP throughput(we dont use Megaflow Cache
+ Microflow Cache) between VMs is 1.18Gbs/sec up to 1.30Gbs/sec
(maybe ~10% performance imporve).
This patch adds cpumask struct, the cpu_used_mask stores the cpu_id
that the flow used. And we only check the flow_stats on the cpu we
used, and it is unncessary to check all possible cpu when getting,
cleaning, and updating the flow_stats. Adding the cpu_used_mask to
sw_flow struct does’t increase the cacheline number.
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-18 09:28:06 +03:00
|
|
|
for (cpu = 0; cpu < nr_cpu_ids; cpu = cpumask_next(cpu, &flow->cpu_used_mask)) {
|
2019-07-19 19:20:13 +03:00
|
|
|
struct sw_flow_stats *stats = rcu_dereference_ovsl(flow->stats[cpu]);
|
openvswitch: Per NUMA node flow stats.
Keep kernel flow stats for each NUMA node rather than each (logical)
CPU. This avoids using the per-CPU allocator and removes most of the
kernel-side OVS locking overhead otherwise on the top of perf reports
and allows OVS to scale better with higher number of threads.
With 9 handlers and 4 revalidators netperf TCP_CRR test flow setup
rate doubles on a server with two hyper-threaded physical CPUs (16
logical cores each) compared to the current OVS master. Tested with
non-trivial flow table with a TCP port match rule forcing all new
connections with unique port numbers to OVS userspace. The IP
addresses are still wildcarded, so the kernel flows are not considered
as exact match 5-tuple flows. This type of flows can be expected to
appear in large numbers as the result of more effective wildcarding
made possible by improvements in OVS userspace flow classifier.
Perf results for this test (master):
Events: 305K cycles
+ 8.43% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 5.64% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 4.75% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 3.32% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 2.61% ovs-vswitchd [kernel.kallsyms] [k] pcpu_alloc_area
+ 2.19% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.03% swapper [kernel.kallsyms] [k] intel_idle
+ 1.84% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 1.64% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.58% ovs-vswitchd libc-2.15.so [.] 0x7f4e6
+ 1.07% ovs-vswitchd [kernel.kallsyms] [k] memset
+ 1.03% netperf [kernel.kallsyms] [k] __ticket_spin_lock
+ 0.92% swapper [kernel.kallsyms] [k] __ticket_spin_lock
...
And after this patch:
Events: 356K cycles
+ 6.85% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 4.63% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 3.06% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 2.81% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.51% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 2.27% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.84% ovs-vswitchd libc-2.15.so [.] 0x15d30f
+ 1.74% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 1.47% swapper [kernel.kallsyms] [k] intel_idle
+ 1.34% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask
+ 1.33% ovs-vswitchd ovs-vswitchd [.] rule_actions_unref
+ 1.16% ovs-vswitchd ovs-vswitchd [.] hindex_node_with_hash
+ 1.16% ovs-vswitchd ovs-vswitchd [.] do_xlate_actions
+ 1.09% ovs-vswitchd ovs-vswitchd [.] ofproto_rule_ref
+ 1.01% netperf [kernel.kallsyms] [k] __ticket_spin_lock
...
There is a small increase in kernel spinlock overhead due to the same
spinlock being shared between multiple cores of the same physical CPU,
but that is barely visible in the netperf TCP_CRR test performance
(maybe ~1% performance drop, hard to tell exactly due to variance in
the test results), when testing for kernel module throughput (with no
userspace activity, handful of kernel flows).
On flow setup, a single stats instance is allocated (for the NUMA node
0). As CPUs from multiple NUMA nodes start updating stats, new
NUMA-node specific stats instances are allocated. This allocation on
the packet processing code path is made to never block or look for
emergency memory pools, minimizing the allocation latency. If the
allocation fails, the existing preallocated stats instance is used.
Also, if only CPUs from one NUMA-node are updating the preallocated
stats instance, no additional stats instances are allocated. This
eliminates the need to pre-allocate stats instances that will not be
used, also relieving the stats reader from the burden of reading stats
that are never used.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
2014-03-27 23:42:54 +04:00
|
|
|
|
|
|
|
if (stats) {
|
|
|
|
/* Local CPU may write on non-local stats, so we must
|
|
|
|
* block bottom-halves here.
|
|
|
|
*/
|
|
|
|
spin_lock_bh(&stats->lock);
|
|
|
|
if (!*used || time_after(stats->used, *used))
|
|
|
|
*used = stats->used;
|
|
|
|
*tcp_flags |= stats->tcp_flags;
|
|
|
|
ovs_stats->n_packets += stats->packet_count;
|
|
|
|
ovs_stats->n_bytes += stats->byte_count;
|
|
|
|
spin_unlock_bh(&stats->lock);
|
|
|
|
}
|
2013-10-30 04:22:21 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-05-06 01:17:28 +04:00
|
|
|
/* Called with ovs_mutex. */
|
2013-10-30 04:22:21 +04:00
|
|
|
void ovs_flow_stats_clear(struct sw_flow *flow)
|
|
|
|
{
|
2016-09-16 01:11:53 +03:00
|
|
|
int cpu;
|
openvswitch: Per NUMA node flow stats.
Keep kernel flow stats for each NUMA node rather than each (logical)
CPU. This avoids using the per-CPU allocator and removes most of the
kernel-side OVS locking overhead otherwise on the top of perf reports
and allows OVS to scale better with higher number of threads.
With 9 handlers and 4 revalidators netperf TCP_CRR test flow setup
rate doubles on a server with two hyper-threaded physical CPUs (16
logical cores each) compared to the current OVS master. Tested with
non-trivial flow table with a TCP port match rule forcing all new
connections with unique port numbers to OVS userspace. The IP
addresses are still wildcarded, so the kernel flows are not considered
as exact match 5-tuple flows. This type of flows can be expected to
appear in large numbers as the result of more effective wildcarding
made possible by improvements in OVS userspace flow classifier.
Perf results for this test (master):
Events: 305K cycles
+ 8.43% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 5.64% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 4.75% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 3.32% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 2.61% ovs-vswitchd [kernel.kallsyms] [k] pcpu_alloc_area
+ 2.19% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.03% swapper [kernel.kallsyms] [k] intel_idle
+ 1.84% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 1.64% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.58% ovs-vswitchd libc-2.15.so [.] 0x7f4e6
+ 1.07% ovs-vswitchd [kernel.kallsyms] [k] memset
+ 1.03% netperf [kernel.kallsyms] [k] __ticket_spin_lock
+ 0.92% swapper [kernel.kallsyms] [k] __ticket_spin_lock
...
And after this patch:
Events: 356K cycles
+ 6.85% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 4.63% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 3.06% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 2.81% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.51% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 2.27% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.84% ovs-vswitchd libc-2.15.so [.] 0x15d30f
+ 1.74% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 1.47% swapper [kernel.kallsyms] [k] intel_idle
+ 1.34% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask
+ 1.33% ovs-vswitchd ovs-vswitchd [.] rule_actions_unref
+ 1.16% ovs-vswitchd ovs-vswitchd [.] hindex_node_with_hash
+ 1.16% ovs-vswitchd ovs-vswitchd [.] do_xlate_actions
+ 1.09% ovs-vswitchd ovs-vswitchd [.] ofproto_rule_ref
+ 1.01% netperf [kernel.kallsyms] [k] __ticket_spin_lock
...
There is a small increase in kernel spinlock overhead due to the same
spinlock being shared between multiple cores of the same physical CPU,
but that is barely visible in the netperf TCP_CRR test performance
(maybe ~1% performance drop, hard to tell exactly due to variance in
the test results), when testing for kernel module throughput (with no
userspace activity, handful of kernel flows).
On flow setup, a single stats instance is allocated (for the NUMA node
0). As CPUs from multiple NUMA nodes start updating stats, new
NUMA-node specific stats instances are allocated. This allocation on
the packet processing code path is made to never block or look for
emergency memory pools, minimizing the allocation latency. If the
allocation fails, the existing preallocated stats instance is used.
Also, if only CPUs from one NUMA-node are updating the preallocated
stats instance, no additional stats instances are allocated. This
eliminates the need to pre-allocate stats instances that will not be
used, also relieving the stats reader from the burden of reading stats
that are never used.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
2014-03-27 23:42:54 +04:00
|
|
|
|
2016-09-16 01:11:53 +03:00
|
|
|
/* We open code this to make sure cpu 0 is always considered */
|
openvswitch: Optimize operations for OvS flow_stats.
When calling the flow_free() to free the flow, we call many times
(cpu_possible_mask, eg. 128 as default) cpumask_next(). That will
take up our CPU usage if we call the flow_free() frequently.
When we put all packets to userspace via upcall, and OvS will send
them back via netlink to ovs_packet_cmd_execute(will call flow_free).
The test topo is shown as below. VM01 sends TCP packets to VM02,
and OvS forward packtets. When testing, we use perf to report the
system performance.
VM01 --- OvS-VM --- VM02
Without this patch, perf-top show as below: The flow_free() is
3.02% CPU usage.
4.23% [kernel] [k] _raw_spin_unlock_irqrestore
3.62% [kernel] [k] __do_softirq
3.16% [kernel] [k] __memcpy
3.02% [kernel] [k] flow_free
2.42% libc-2.17.so [.] __memcpy_ssse3_back
2.18% [kernel] [k] copy_user_generic_unrolled
2.17% [kernel] [k] find_next_bit
When applied this patch, perf-top show as below: Not shown on
the list anymore.
4.11% [kernel] [k] _raw_spin_unlock_irqrestore
3.79% [kernel] [k] __do_softirq
3.46% [kernel] [k] __memcpy
2.73% libc-2.17.so [.] __memcpy_ssse3_back
2.25% [kernel] [k] copy_user_generic_unrolled
1.89% libc-2.17.so [.] _int_malloc
1.53% ovs-vswitchd [.] xlate_actions
With this patch, the TCP throughput(we dont use Megaflow Cache
+ Microflow Cache) between VMs is 1.18Gbs/sec up to 1.30Gbs/sec
(maybe ~10% performance imporve).
This patch adds cpumask struct, the cpu_used_mask stores the cpu_id
that the flow used. And we only check the flow_stats on the cpu we
used, and it is unncessary to check all possible cpu when getting,
cleaning, and updating the flow_stats. Adding the cpu_used_mask to
sw_flow struct does’t increase the cacheline number.
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-18 09:28:06 +03:00
|
|
|
for (cpu = 0; cpu < nr_cpu_ids; cpu = cpumask_next(cpu, &flow->cpu_used_mask)) {
|
2019-07-19 19:20:13 +03:00
|
|
|
struct sw_flow_stats *stats = ovsl_dereference(flow->stats[cpu]);
|
openvswitch: Per NUMA node flow stats.
Keep kernel flow stats for each NUMA node rather than each (logical)
CPU. This avoids using the per-CPU allocator and removes most of the
kernel-side OVS locking overhead otherwise on the top of perf reports
and allows OVS to scale better with higher number of threads.
With 9 handlers and 4 revalidators netperf TCP_CRR test flow setup
rate doubles on a server with two hyper-threaded physical CPUs (16
logical cores each) compared to the current OVS master. Tested with
non-trivial flow table with a TCP port match rule forcing all new
connections with unique port numbers to OVS userspace. The IP
addresses are still wildcarded, so the kernel flows are not considered
as exact match 5-tuple flows. This type of flows can be expected to
appear in large numbers as the result of more effective wildcarding
made possible by improvements in OVS userspace flow classifier.
Perf results for this test (master):
Events: 305K cycles
+ 8.43% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 5.64% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 4.75% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 3.32% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 2.61% ovs-vswitchd [kernel.kallsyms] [k] pcpu_alloc_area
+ 2.19% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.03% swapper [kernel.kallsyms] [k] intel_idle
+ 1.84% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 1.64% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.58% ovs-vswitchd libc-2.15.so [.] 0x7f4e6
+ 1.07% ovs-vswitchd [kernel.kallsyms] [k] memset
+ 1.03% netperf [kernel.kallsyms] [k] __ticket_spin_lock
+ 0.92% swapper [kernel.kallsyms] [k] __ticket_spin_lock
...
And after this patch:
Events: 356K cycles
+ 6.85% ovs-vswitchd ovs-vswitchd [.] find_match_wc
+ 4.63% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_lock
+ 3.06% ovs-vswitchd [kernel.kallsyms] [k] __ticket_spin_lock
+ 2.81% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask_range
+ 2.51% ovs-vswitchd libpthread-2.15.so [.] pthread_mutex_unlock
+ 2.27% ovs-vswitchd ovs-vswitchd [.] classifier_lookup
+ 1.84% ovs-vswitchd libc-2.15.so [.] 0x15d30f
+ 1.74% ovs-vswitchd [kernel.kallsyms] [k] mutex_spin_on_owner
+ 1.47% swapper [kernel.kallsyms] [k] intel_idle
+ 1.34% ovs-vswitchd ovs-vswitchd [.] flow_hash_in_minimask
+ 1.33% ovs-vswitchd ovs-vswitchd [.] rule_actions_unref
+ 1.16% ovs-vswitchd ovs-vswitchd [.] hindex_node_with_hash
+ 1.16% ovs-vswitchd ovs-vswitchd [.] do_xlate_actions
+ 1.09% ovs-vswitchd ovs-vswitchd [.] ofproto_rule_ref
+ 1.01% netperf [kernel.kallsyms] [k] __ticket_spin_lock
...
There is a small increase in kernel spinlock overhead due to the same
spinlock being shared between multiple cores of the same physical CPU,
but that is barely visible in the netperf TCP_CRR test performance
(maybe ~1% performance drop, hard to tell exactly due to variance in
the test results), when testing for kernel module throughput (with no
userspace activity, handful of kernel flows).
On flow setup, a single stats instance is allocated (for the NUMA node
0). As CPUs from multiple NUMA nodes start updating stats, new
NUMA-node specific stats instances are allocated. This allocation on
the packet processing code path is made to never block or look for
emergency memory pools, minimizing the allocation latency. If the
allocation fails, the existing preallocated stats instance is used.
Also, if only CPUs from one NUMA-node are updating the preallocated
stats instance, no additional stats instances are allocated. This
eliminates the need to pre-allocate stats instances that will not be
used, also relieving the stats reader from the burden of reading stats
that are never used.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
2014-03-27 23:42:54 +04:00
|
|
|
|
|
|
|
if (stats) {
|
|
|
|
spin_lock_bh(&stats->lock);
|
|
|
|
stats->used = 0;
|
|
|
|
stats->packet_count = 0;
|
|
|
|
stats->byte_count = 0;
|
|
|
|
stats->tcp_flags = 0;
|
|
|
|
spin_unlock_bh(&stats->lock);
|
|
|
|
}
|
|
|
|
}
|
2013-08-08 07:01:00 +04:00
|
|
|
}
|
|
|
|
|
2011-10-26 06:26:31 +04:00
|
|
|
static int check_header(struct sk_buff *skb, int len)
|
|
|
|
{
|
|
|
|
if (unlikely(skb->len < len))
|
|
|
|
return -EINVAL;
|
|
|
|
if (unlikely(!pskb_may_pull(skb, len)))
|
|
|
|
return -ENOMEM;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool arphdr_ok(struct sk_buff *skb)
|
|
|
|
{
|
|
|
|
return pskb_may_pull(skb, skb_network_offset(skb) +
|
|
|
|
sizeof(struct arp_eth_header));
|
|
|
|
}
|
|
|
|
|
|
|
|
static int check_iphdr(struct sk_buff *skb)
|
|
|
|
{
|
|
|
|
unsigned int nh_ofs = skb_network_offset(skb);
|
|
|
|
unsigned int ip_len;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
err = check_header(skb, nh_ofs + sizeof(struct iphdr));
|
|
|
|
if (unlikely(err))
|
|
|
|
return err;
|
|
|
|
|
|
|
|
ip_len = ip_hdrlen(skb);
|
|
|
|
if (unlikely(ip_len < sizeof(struct iphdr) ||
|
|
|
|
skb->len < nh_ofs + ip_len))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
skb_set_transport_header(skb, nh_ofs + ip_len);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool tcphdr_ok(struct sk_buff *skb)
|
|
|
|
{
|
|
|
|
int th_ofs = skb_transport_offset(skb);
|
|
|
|
int tcp_len;
|
|
|
|
|
|
|
|
if (unlikely(!pskb_may_pull(skb, th_ofs + sizeof(struct tcphdr))))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
tcp_len = tcp_hdrlen(skb);
|
|
|
|
if (unlikely(tcp_len < sizeof(struct tcphdr) ||
|
|
|
|
skb->len < th_ofs + tcp_len))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool udphdr_ok(struct sk_buff *skb)
|
|
|
|
{
|
|
|
|
return pskb_may_pull(skb, skb_transport_offset(skb) +
|
|
|
|
sizeof(struct udphdr));
|
|
|
|
}
|
|
|
|
|
2013-08-22 23:30:48 +04:00
|
|
|
static bool sctphdr_ok(struct sk_buff *skb)
|
|
|
|
{
|
|
|
|
return pskb_may_pull(skb, skb_transport_offset(skb) +
|
|
|
|
sizeof(struct sctphdr));
|
|
|
|
}
|
|
|
|
|
2011-10-26 06:26:31 +04:00
|
|
|
static bool icmphdr_ok(struct sk_buff *skb)
|
|
|
|
{
|
|
|
|
return pskb_may_pull(skb, skb_transport_offset(skb) +
|
|
|
|
sizeof(struct icmphdr));
|
|
|
|
}
|
|
|
|
|
2013-08-08 07:01:00 +04:00
|
|
|
static int parse_ipv6hdr(struct sk_buff *skb, struct sw_flow_key *key)
|
2011-10-26 06:26:31 +04:00
|
|
|
{
|
2018-09-05 01:33:41 +03:00
|
|
|
unsigned short frag_off;
|
|
|
|
unsigned int payload_ofs = 0;
|
2011-10-26 06:26:31 +04:00
|
|
|
unsigned int nh_ofs = skb_network_offset(skb);
|
|
|
|
unsigned int nh_len;
|
|
|
|
struct ipv6hdr *nh;
|
2018-09-05 01:33:41 +03:00
|
|
|
int err, nexthdr, flags = 0;
|
2011-10-26 06:26:31 +04:00
|
|
|
|
|
|
|
err = check_header(skb, nh_ofs + sizeof(*nh));
|
|
|
|
if (unlikely(err))
|
|
|
|
return err;
|
|
|
|
|
|
|
|
nh = ipv6_hdr(skb);
|
|
|
|
|
|
|
|
key->ip.proto = NEXTHDR_NONE;
|
|
|
|
key->ip.tos = ipv6_get_dsfield(nh);
|
|
|
|
key->ip.ttl = nh->hop_limit;
|
|
|
|
key->ipv6.label = *(__be32 *)nh & htonl(IPV6_FLOWINFO_FLOWLABEL);
|
|
|
|
key->ipv6.addr.src = nh->saddr;
|
|
|
|
key->ipv6.addr.dst = nh->daddr;
|
|
|
|
|
2018-09-05 01:33:41 +03:00
|
|
|
nexthdr = ipv6_find_hdr(skb, &payload_ofs, -1, &frag_off, &flags);
|
|
|
|
if (flags & IP6_FH_F_FRAG) {
|
2019-01-03 20:51:57 +03:00
|
|
|
if (frag_off) {
|
2011-10-26 06:26:31 +04:00
|
|
|
key->ip.frag = OVS_FRAG_TYPE_LATER;
|
2019-01-03 20:51:57 +03:00
|
|
|
key->ip.proto = nexthdr;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
key->ip.frag = OVS_FRAG_TYPE_FIRST;
|
2014-10-18 00:56:31 +04:00
|
|
|
} else {
|
|
|
|
key->ip.frag = OVS_FRAG_TYPE_NONE;
|
2011-10-26 06:26:31 +04:00
|
|
|
}
|
|
|
|
|
2018-09-05 01:33:41 +03:00
|
|
|
/* Delayed handling of error in ipv6_find_hdr() as it
|
|
|
|
* always sets flags and frag_off to a valid value which may be
|
2015-08-29 03:02:21 +03:00
|
|
|
* used to set key->ip.frag above.
|
|
|
|
*/
|
2018-09-05 01:33:41 +03:00
|
|
|
if (unlikely(nexthdr < 0))
|
2015-08-29 03:02:21 +03:00
|
|
|
return -EPROTO;
|
|
|
|
|
2011-10-26 06:26:31 +04:00
|
|
|
nh_len = payload_ofs - nh_ofs;
|
|
|
|
skb_set_transport_header(skb, nh_ofs + nh_len);
|
|
|
|
key->ip.proto = nexthdr;
|
|
|
|
return nh_len;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool icmp6hdr_ok(struct sk_buff *skb)
|
|
|
|
{
|
|
|
|
return pskb_may_pull(skb, skb_transport_offset(skb) +
|
|
|
|
sizeof(struct icmp6hdr));
|
|
|
|
}
|
|
|
|
|
2016-09-07 19:56:59 +03:00
|
|
|
/**
|
2021-08-08 22:08:34 +03:00
|
|
|
* parse_vlan_tag - Parse vlan tag from vlan header.
|
2020-10-28 03:48:49 +03:00
|
|
|
* @skb: skb containing frame to parse
|
|
|
|
* @key_vh: pointer to parsed vlan tag
|
|
|
|
* @untag_vlan: should the vlan header be removed from the frame
|
|
|
|
*
|
2021-08-08 22:08:34 +03:00
|
|
|
* Return: ERROR on memory error.
|
|
|
|
* %0 if it encounters a non-vlan or incomplete packet.
|
|
|
|
* %1 after successfully parsing vlan tag.
|
2016-09-07 19:56:59 +03:00
|
|
|
*/
|
2016-12-26 19:31:27 +03:00
|
|
|
static int parse_vlan_tag(struct sk_buff *skb, struct vlan_head *key_vh,
|
|
|
|
bool untag_vlan)
|
2011-10-26 06:26:31 +04:00
|
|
|
{
|
2016-09-07 19:56:59 +03:00
|
|
|
struct vlan_head *vh = (struct vlan_head *)skb->data;
|
2011-10-26 06:26:31 +04:00
|
|
|
|
2016-09-07 19:56:59 +03:00
|
|
|
if (likely(!eth_type_vlan(vh->tpid)))
|
2011-10-26 06:26:31 +04:00
|
|
|
return 0;
|
|
|
|
|
2016-09-07 19:56:59 +03:00
|
|
|
if (unlikely(skb->len < sizeof(struct vlan_head) + sizeof(__be16)))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (unlikely(!pskb_may_pull(skb, sizeof(struct vlan_head) +
|
|
|
|
sizeof(__be16))))
|
2011-10-26 06:26:31 +04:00
|
|
|
return -ENOMEM;
|
|
|
|
|
2016-09-07 19:56:59 +03:00
|
|
|
vh = (struct vlan_head *)skb->data;
|
2018-11-08 20:44:50 +03:00
|
|
|
key_vh->tci = vh->tci | htons(VLAN_CFI_MASK);
|
2016-09-07 19:56:59 +03:00
|
|
|
key_vh->tpid = vh->tpid;
|
|
|
|
|
2016-12-26 19:31:27 +03:00
|
|
|
if (unlikely(untag_vlan)) {
|
|
|
|
int offset = skb->data - skb_mac_header(skb);
|
|
|
|
u16 tci;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
__skb_push(skb, offset);
|
|
|
|
err = __skb_vlan_pop(skb, &tci);
|
|
|
|
__skb_pull(skb, offset);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
__vlan_hwaccel_put_tag(skb, key_vh->tpid, tci);
|
|
|
|
} else {
|
|
|
|
__skb_pull(skb, sizeof(struct vlan_head));
|
|
|
|
}
|
2016-09-07 19:56:59 +03:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2016-11-10 18:28:21 +03:00
|
|
|
static void clear_vlan(struct sw_flow_key *key)
|
2016-09-07 19:56:59 +03:00
|
|
|
{
|
|
|
|
key->eth.vlan.tci = 0;
|
|
|
|
key->eth.vlan.tpid = 0;
|
|
|
|
key->eth.cvlan.tci = 0;
|
|
|
|
key->eth.cvlan.tpid = 0;
|
2016-11-10 18:28:21 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static int parse_vlan(struct sk_buff *skb, struct sw_flow_key *key)
|
|
|
|
{
|
|
|
|
int res;
|
2016-09-07 19:56:59 +03:00
|
|
|
|
2016-10-10 18:02:42 +03:00
|
|
|
if (skb_vlan_tag_present(skb)) {
|
2018-11-08 20:44:50 +03:00
|
|
|
key->eth.vlan.tci = htons(skb->vlan_tci) | htons(VLAN_CFI_MASK);
|
2016-09-07 19:56:59 +03:00
|
|
|
key->eth.vlan.tpid = skb->vlan_proto;
|
|
|
|
} else {
|
|
|
|
/* Parse outer vlan tag in the non-accelerated case. */
|
2016-12-26 19:31:27 +03:00
|
|
|
res = parse_vlan_tag(skb, &key->eth.vlan, true);
|
2016-09-07 19:56:59 +03:00
|
|
|
if (res <= 0)
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Parse inner vlan tag. */
|
2016-12-26 19:31:27 +03:00
|
|
|
res = parse_vlan_tag(skb, &key->eth.cvlan, false);
|
2016-09-07 19:56:59 +03:00
|
|
|
if (res <= 0)
|
|
|
|
return res;
|
2011-10-26 06:26:31 +04:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static __be16 parse_ethertype(struct sk_buff *skb)
|
|
|
|
{
|
|
|
|
struct llc_snap_hdr {
|
|
|
|
u8 dsap; /* Always 0xAA */
|
|
|
|
u8 ssap; /* Always 0xAA */
|
|
|
|
u8 ctrl;
|
|
|
|
u8 oui[3];
|
|
|
|
__be16 ethertype;
|
|
|
|
};
|
|
|
|
struct llc_snap_hdr *llc;
|
|
|
|
__be16 proto;
|
|
|
|
|
|
|
|
proto = *(__be16 *) skb->data;
|
|
|
|
__skb_pull(skb, sizeof(__be16));
|
|
|
|
|
2015-05-05 00:34:05 +03:00
|
|
|
if (eth_proto_is_802_3(proto))
|
2011-10-26 06:26:31 +04:00
|
|
|
return proto;
|
|
|
|
|
|
|
|
if (skb->len < sizeof(struct llc_snap_hdr))
|
|
|
|
return htons(ETH_P_802_2);
|
|
|
|
|
|
|
|
if (unlikely(!pskb_may_pull(skb, sizeof(struct llc_snap_hdr))))
|
|
|
|
return htons(0);
|
|
|
|
|
|
|
|
llc = (struct llc_snap_hdr *) skb->data;
|
|
|
|
if (llc->dsap != LLC_SAP_SNAP ||
|
|
|
|
llc->ssap != LLC_SAP_SNAP ||
|
|
|
|
(llc->oui[0] | llc->oui[1] | llc->oui[2]) != 0)
|
|
|
|
return htons(ETH_P_802_2);
|
|
|
|
|
|
|
|
__skb_pull(skb, sizeof(struct llc_snap_hdr));
|
2013-02-19 23:10:30 +04:00
|
|
|
|
2015-05-05 00:34:05 +03:00
|
|
|
if (eth_proto_is_802_3(llc->ethertype))
|
2013-02-19 23:10:30 +04:00
|
|
|
return llc->ethertype;
|
|
|
|
|
|
|
|
return htons(ETH_P_802_2);
|
2011-10-26 06:26:31 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key,
|
2013-08-08 07:01:00 +04:00
|
|
|
int nh_len)
|
2011-10-26 06:26:31 +04:00
|
|
|
{
|
|
|
|
struct icmp6hdr *icmp = icmp6_hdr(skb);
|
|
|
|
|
|
|
|
/* The ICMPv6 type and code fields use the 16-bit transport port
|
|
|
|
* fields, so we need to store them in 16-bit network byte order.
|
|
|
|
*/
|
2014-05-05 20:54:49 +04:00
|
|
|
key->tp.src = htons(icmp->icmp6_type);
|
|
|
|
key->tp.dst = htons(icmp->icmp6_code);
|
2014-10-18 00:56:31 +04:00
|
|
|
memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd));
|
2011-10-26 06:26:31 +04:00
|
|
|
|
|
|
|
if (icmp->icmp6_code == 0 &&
|
|
|
|
(icmp->icmp6_type == NDISC_NEIGHBOUR_SOLICITATION ||
|
|
|
|
icmp->icmp6_type == NDISC_NEIGHBOUR_ADVERTISEMENT)) {
|
|
|
|
int icmp_len = skb->len - skb_transport_offset(skb);
|
|
|
|
struct nd_msg *nd;
|
|
|
|
int offset;
|
|
|
|
|
|
|
|
/* In order to process neighbor discovery options, we need the
|
|
|
|
* entire packet.
|
|
|
|
*/
|
|
|
|
if (unlikely(icmp_len < sizeof(*nd)))
|
2013-08-08 07:01:00 +04:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (unlikely(skb_linearize(skb)))
|
|
|
|
return -ENOMEM;
|
2011-10-26 06:26:31 +04:00
|
|
|
|
|
|
|
nd = (struct nd_msg *)skb_transport_header(skb);
|
|
|
|
key->ipv6.nd.target = nd->target;
|
|
|
|
|
|
|
|
icmp_len -= sizeof(*nd);
|
|
|
|
offset = 0;
|
|
|
|
while (icmp_len >= 8) {
|
|
|
|
struct nd_opt_hdr *nd_opt =
|
|
|
|
(struct nd_opt_hdr *)(nd->opt + offset);
|
|
|
|
int opt_len = nd_opt->nd_opt_len * 8;
|
|
|
|
|
|
|
|
if (unlikely(!opt_len || opt_len > icmp_len))
|
2013-08-08 07:01:00 +04:00
|
|
|
return 0;
|
2011-10-26 06:26:31 +04:00
|
|
|
|
|
|
|
/* Store the link layer address if the appropriate
|
|
|
|
* option is provided. It is considered an error if
|
|
|
|
* the same link layer option is specified twice.
|
|
|
|
*/
|
|
|
|
if (nd_opt->nd_opt_type == ND_OPT_SOURCE_LL_ADDR
|
|
|
|
&& opt_len == 8) {
|
|
|
|
if (unlikely(!is_zero_ether_addr(key->ipv6.nd.sll)))
|
|
|
|
goto invalid;
|
2014-02-18 23:15:45 +04:00
|
|
|
ether_addr_copy(key->ipv6.nd.sll,
|
|
|
|
&nd->opt[offset+sizeof(*nd_opt)]);
|
2011-10-26 06:26:31 +04:00
|
|
|
} else if (nd_opt->nd_opt_type == ND_OPT_TARGET_LL_ADDR
|
|
|
|
&& opt_len == 8) {
|
|
|
|
if (unlikely(!is_zero_ether_addr(key->ipv6.nd.tll)))
|
|
|
|
goto invalid;
|
2014-02-18 23:15:45 +04:00
|
|
|
ether_addr_copy(key->ipv6.nd.tll,
|
|
|
|
&nd->opt[offset+sizeof(*nd_opt)]);
|
2011-10-26 06:26:31 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
icmp_len -= opt_len;
|
|
|
|
offset += opt_len;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-08-08 07:01:00 +04:00
|
|
|
return 0;
|
2011-10-26 06:26:31 +04:00
|
|
|
|
|
|
|
invalid:
|
|
|
|
memset(&key->ipv6.nd.target, 0, sizeof(key->ipv6.nd.target));
|
|
|
|
memset(key->ipv6.nd.sll, 0, sizeof(key->ipv6.nd.sll));
|
|
|
|
memset(key->ipv6.nd.tll, 0, sizeof(key->ipv6.nd.tll));
|
|
|
|
|
2013-08-08 07:01:00 +04:00
|
|
|
return 0;
|
2011-10-26 06:26:31 +04:00
|
|
|
}
|
|
|
|
|
2017-11-07 16:07:02 +03:00
|
|
|
static int parse_nsh(struct sk_buff *skb, struct sw_flow_key *key)
|
|
|
|
{
|
|
|
|
struct nshhdr *nh;
|
|
|
|
unsigned int nh_ofs = skb_network_offset(skb);
|
|
|
|
u8 version, length;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
err = check_header(skb, nh_ofs + NSH_BASE_HDR_LEN);
|
|
|
|
if (unlikely(err))
|
|
|
|
return err;
|
|
|
|
|
|
|
|
nh = nsh_hdr(skb);
|
|
|
|
version = nsh_get_ver(nh);
|
|
|
|
length = nsh_hdr_len(nh);
|
|
|
|
|
|
|
|
if (version != 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
err = check_header(skb, nh_ofs + length);
|
|
|
|
if (unlikely(err))
|
|
|
|
return err;
|
|
|
|
|
|
|
|
nh = nsh_hdr(skb);
|
|
|
|
key->nsh.base.flags = nsh_get_flags(nh);
|
|
|
|
key->nsh.base.ttl = nsh_get_ttl(nh);
|
|
|
|
key->nsh.base.mdtype = nh->mdtype;
|
|
|
|
key->nsh.base.np = nh->np;
|
|
|
|
key->nsh.base.path_hdr = nh->path_hdr;
|
|
|
|
switch (key->nsh.base.mdtype) {
|
|
|
|
case NSH_M_TYPE1:
|
|
|
|
if (length != NSH_M_TYPE1_LEN)
|
|
|
|
return -EINVAL;
|
|
|
|
memcpy(key->nsh.context, nh->md1.context,
|
|
|
|
sizeof(nh->md1));
|
|
|
|
break;
|
|
|
|
case NSH_M_TYPE2:
|
|
|
|
memset(key->nsh.context, 0,
|
|
|
|
sizeof(nh->md1));
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-10-26 06:26:31 +04:00
|
|
|
/**
|
2019-08-27 17:58:09 +03:00
|
|
|
* key_extract_l3l4 - extracts L3/L4 header information.
|
2011-10-26 06:26:31 +04:00
|
|
|
* @skb: sk_buff that contains the frame, with skb->data pointing to the
|
2019-08-27 17:58:09 +03:00
|
|
|
* L3 header
|
2011-10-26 06:26:31 +04:00
|
|
|
* @key: output flow key
|
|
|
|
*
|
2021-08-08 22:08:34 +03:00
|
|
|
* Return: %0 if successful, otherwise a negative errno value.
|
2011-10-26 06:26:31 +04:00
|
|
|
*/
|
2019-08-27 17:58:09 +03:00
|
|
|
static int key_extract_l3l4(struct sk_buff *skb, struct sw_flow_key *key)
|
2011-10-26 06:26:31 +04:00
|
|
|
{
|
2013-08-08 07:01:00 +04:00
|
|
|
int error;
|
2011-10-26 06:26:31 +04:00
|
|
|
|
|
|
|
/* Network layer. */
|
|
|
|
if (key->eth.type == htons(ETH_P_IP)) {
|
|
|
|
struct iphdr *nh;
|
|
|
|
__be16 offset;
|
|
|
|
|
|
|
|
error = check_iphdr(skb);
|
|
|
|
if (unlikely(error)) {
|
2014-10-04 02:35:29 +04:00
|
|
|
memset(&key->ip, 0, sizeof(key->ip));
|
|
|
|
memset(&key->ipv4, 0, sizeof(key->ipv4));
|
2011-10-26 06:26:31 +04:00
|
|
|
if (error == -EINVAL) {
|
|
|
|
skb->transport_header = skb->network_header;
|
|
|
|
error = 0;
|
|
|
|
}
|
2013-08-08 07:01:00 +04:00
|
|
|
return error;
|
2011-10-26 06:26:31 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
nh = ip_hdr(skb);
|
|
|
|
key->ipv4.addr.src = nh->saddr;
|
|
|
|
key->ipv4.addr.dst = nh->daddr;
|
|
|
|
|
|
|
|
key->ip.proto = nh->protocol;
|
|
|
|
key->ip.tos = nh->tos;
|
|
|
|
key->ip.ttl = nh->ttl;
|
|
|
|
|
|
|
|
offset = nh->frag_off & htons(IP_OFFSET);
|
|
|
|
if (offset) {
|
|
|
|
key->ip.frag = OVS_FRAG_TYPE_LATER;
|
2019-08-27 17:58:10 +03:00
|
|
|
memset(&key->tp, 0, sizeof(key->tp));
|
2013-08-08 07:01:00 +04:00
|
|
|
return 0;
|
2011-10-26 06:26:31 +04:00
|
|
|
}
|
net: accept UFO datagrams from tuntap and packet
Tuntap and similar devices can inject GSO packets. Accept type
VIRTIO_NET_HDR_GSO_UDP, even though not generating UFO natively.
Processes are expected to use feature negotiation such as TUNSETOFFLOAD
to detect supported offload types and refrain from injecting other
packets. This process breaks down with live migration: guest kernels
do not renegotiate flags, so destination hosts need to expose all
features that the source host does.
Partially revert the UFO removal from 182e0b6b5846~1..d9d30adf5677.
This patch introduces nearly(*) no new code to simplify verification.
It brings back verbatim tuntap UFO negotiation, VIRTIO_NET_HDR_GSO_UDP
insertion and software UFO segmentation.
It does not reinstate protocol stack support, hardware offload
(NETIF_F_UFO), SKB_GSO_UDP tunneling in SKB_GSO_SOFTWARE or reception
of VIRTIO_NET_HDR_GSO_UDP packets in tuntap.
To support SKB_GSO_UDP reappearing in the stack, also reinstate
logic in act_csum and openvswitch. Achieve equivalence with v4.13 HEAD
by squashing in commit 939912216fa8 ("net: skb_needs_check() removes
CHECKSUM_UNNECESSARY check for tx.") and reverting commit 8d63bee643f1
("net: avoid skb_warn_bad_offload false positives on UFO").
(*) To avoid having to bring back skb_shinfo(skb)->ip6_frag_id,
ipv6_proxy_select_ident is changed to return a __be32 and this is
assigned directly to the frag_hdr. Also, SKB_GSO_UDP is inserted
at the end of the enum to minimize code churn.
Tested
Booted a v4.13 guest kernel with QEMU. On a host kernel before this
patch `ethtool -k eth0` shows UFO disabled. After the patch, it is
enabled, same as on a v4.13 host kernel.
A UFO packet sent from the guest appears on the tap device:
host:
nc -l -p -u 8000 &
tcpdump -n -i tap0
guest:
dd if=/dev/zero of=payload.txt bs=1 count=2000
nc -u 192.16.1.1 8000 < payload.txt
Direct tap to tap transmission of VIRTIO_NET_HDR_GSO_UDP succeeds,
packets arriving fragmented:
./with_tap_pair.sh ./tap_send_ufo tap0 tap1
(from https://github.com/wdebruij/kerneltools/tree/master/tests)
Changes
v1 -> v2
- simplified set_offload change (review comment)
- documented test procedure
Link: http://lkml.kernel.org/r/<CAF=yD-LuUeDuL9YWPJD9ykOZ0QCjNeznPDr6whqZ9NGMNF12Mw@mail.gmail.com>
Fixes: fb652fdfe837 ("macvlan/macvtap: Remove NETIF_F_UFO advertisement.")
Reported-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-21 18:22:25 +03:00
|
|
|
if (nh->frag_off & htons(IP_MF) ||
|
|
|
|
skb_shinfo(skb)->gso_type & SKB_GSO_UDP)
|
2011-10-26 06:26:31 +04:00
|
|
|
key->ip.frag = OVS_FRAG_TYPE_FIRST;
|
2014-10-04 02:35:29 +04:00
|
|
|
else
|
|
|
|
key->ip.frag = OVS_FRAG_TYPE_NONE;
|
2011-10-26 06:26:31 +04:00
|
|
|
|
|
|
|
/* Transport layer. */
|
|
|
|
if (key->ip.proto == IPPROTO_TCP) {
|
|
|
|
if (tcphdr_ok(skb)) {
|
|
|
|
struct tcphdr *tcp = tcp_hdr(skb);
|
2014-05-05 20:54:49 +04:00
|
|
|
key->tp.src = tcp->source;
|
|
|
|
key->tp.dst = tcp->dest;
|
|
|
|
key->tp.flags = TCP_FLAGS_BE16(tcp);
|
2014-10-04 02:35:29 +04:00
|
|
|
} else {
|
|
|
|
memset(&key->tp, 0, sizeof(key->tp));
|
2011-10-26 06:26:31 +04:00
|
|
|
}
|
2014-10-04 02:35:29 +04:00
|
|
|
|
2011-10-26 06:26:31 +04:00
|
|
|
} else if (key->ip.proto == IPPROTO_UDP) {
|
|
|
|
if (udphdr_ok(skb)) {
|
|
|
|
struct udphdr *udp = udp_hdr(skb);
|
2014-05-05 20:54:49 +04:00
|
|
|
key->tp.src = udp->source;
|
|
|
|
key->tp.dst = udp->dest;
|
2014-10-04 02:35:29 +04:00
|
|
|
} else {
|
|
|
|
memset(&key->tp, 0, sizeof(key->tp));
|
2011-10-26 06:26:31 +04:00
|
|
|
}
|
2013-08-22 23:30:48 +04:00
|
|
|
} else if (key->ip.proto == IPPROTO_SCTP) {
|
|
|
|
if (sctphdr_ok(skb)) {
|
|
|
|
struct sctphdr *sctp = sctp_hdr(skb);
|
2014-05-05 20:54:49 +04:00
|
|
|
key->tp.src = sctp->source;
|
|
|
|
key->tp.dst = sctp->dest;
|
2014-10-04 02:35:29 +04:00
|
|
|
} else {
|
|
|
|
memset(&key->tp, 0, sizeof(key->tp));
|
2013-08-22 23:30:48 +04:00
|
|
|
}
|
2011-10-26 06:26:31 +04:00
|
|
|
} else if (key->ip.proto == IPPROTO_ICMP) {
|
|
|
|
if (icmphdr_ok(skb)) {
|
|
|
|
struct icmphdr *icmp = icmp_hdr(skb);
|
|
|
|
/* The ICMP type and code fields use the 16-bit
|
|
|
|
* transport port fields, so we need to store
|
|
|
|
* them in 16-bit network byte order. */
|
2014-05-05 20:54:49 +04:00
|
|
|
key->tp.src = htons(icmp->type);
|
|
|
|
key->tp.dst = htons(icmp->code);
|
2014-10-04 02:35:29 +04:00
|
|
|
} else {
|
|
|
|
memset(&key->tp, 0, sizeof(key->tp));
|
2011-10-26 06:26:31 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-10-04 02:35:29 +04:00
|
|
|
} else if (key->eth.type == htons(ETH_P_ARP) ||
|
|
|
|
key->eth.type == htons(ETH_P_RARP)) {
|
2011-10-26 06:26:31 +04:00
|
|
|
struct arp_eth_header *arp;
|
2014-10-17 10:03:08 +04:00
|
|
|
bool arp_available = arphdr_ok(skb);
|
2011-10-26 06:26:31 +04:00
|
|
|
|
|
|
|
arp = (struct arp_eth_header *)skb_network_header(skb);
|
|
|
|
|
2014-10-17 10:03:08 +04:00
|
|
|
if (arp_available &&
|
2014-10-04 02:35:29 +04:00
|
|
|
arp->ar_hrd == htons(ARPHRD_ETHER) &&
|
|
|
|
arp->ar_pro == htons(ETH_P_IP) &&
|
|
|
|
arp->ar_hln == ETH_ALEN &&
|
|
|
|
arp->ar_pln == 4) {
|
2011-10-26 06:26:31 +04:00
|
|
|
|
|
|
|
/* We only match on the lower 8 bits of the opcode. */
|
|
|
|
if (ntohs(arp->ar_op) <= 0xff)
|
|
|
|
key->ip.proto = ntohs(arp->ar_op);
|
2014-10-04 02:35:29 +04:00
|
|
|
else
|
|
|
|
key->ip.proto = 0;
|
|
|
|
|
2012-10-31 02:50:28 +04:00
|
|
|
memcpy(&key->ipv4.addr.src, arp->ar_sip, sizeof(key->ipv4.addr.src));
|
|
|
|
memcpy(&key->ipv4.addr.dst, arp->ar_tip, sizeof(key->ipv4.addr.dst));
|
2014-02-18 23:15:45 +04:00
|
|
|
ether_addr_copy(key->ipv4.arp.sha, arp->ar_sha);
|
|
|
|
ether_addr_copy(key->ipv4.arp.tha, arp->ar_tha);
|
2014-10-04 02:35:29 +04:00
|
|
|
} else {
|
|
|
|
memset(&key->ip, 0, sizeof(key->ip));
|
|
|
|
memset(&key->ipv4, 0, sizeof(key->ipv4));
|
2011-10-26 06:26:31 +04:00
|
|
|
}
|
2014-10-06 16:05:13 +04:00
|
|
|
} else if (eth_p_mpls(key->eth.type)) {
|
2019-11-04 04:57:44 +03:00
|
|
|
u8 label_count = 1;
|
2014-10-06 16:05:13 +04:00
|
|
|
|
2019-11-04 04:57:44 +03:00
|
|
|
memset(&key->mpls, 0, sizeof(key->mpls));
|
2016-09-30 20:08:05 +03:00
|
|
|
skb_set_inner_network_header(skb, skb->mac_len);
|
2014-10-06 16:05:13 +04:00
|
|
|
while (1) {
|
|
|
|
__be32 lse;
|
|
|
|
|
2019-11-04 04:57:44 +03:00
|
|
|
error = check_header(skb, skb->mac_len +
|
|
|
|
label_count * MPLS_HLEN);
|
2014-10-06 16:05:13 +04:00
|
|
|
if (unlikely(error))
|
|
|
|
return 0;
|
|
|
|
|
2016-09-30 20:08:05 +03:00
|
|
|
memcpy(&lse, skb_inner_network_header(skb), MPLS_HLEN);
|
2014-10-06 16:05:13 +04:00
|
|
|
|
2019-11-04 04:57:44 +03:00
|
|
|
if (label_count <= MPLS_LABEL_DEPTH)
|
|
|
|
memcpy(&key->mpls.lse[label_count - 1], &lse,
|
|
|
|
MPLS_HLEN);
|
2014-10-06 16:05:13 +04:00
|
|
|
|
2019-11-04 04:57:44 +03:00
|
|
|
skb_set_inner_network_header(skb, skb->mac_len +
|
|
|
|
label_count * MPLS_HLEN);
|
2014-10-06 16:05:13 +04:00
|
|
|
if (lse & htonl(MPLS_LS_S_MASK))
|
|
|
|
break;
|
|
|
|
|
2019-11-04 04:57:44 +03:00
|
|
|
label_count++;
|
2014-10-06 16:05:13 +04:00
|
|
|
}
|
2019-11-04 04:57:44 +03:00
|
|
|
if (label_count > MPLS_LABEL_DEPTH)
|
|
|
|
label_count = MPLS_LABEL_DEPTH;
|
|
|
|
|
|
|
|
key->mpls.num_labels_mask = GENMASK(label_count - 1, 0);
|
2011-10-26 06:26:31 +04:00
|
|
|
} else if (key->eth.type == htons(ETH_P_IPV6)) {
|
|
|
|
int nh_len; /* IPv6 Header + Extensions */
|
|
|
|
|
2013-08-08 07:01:00 +04:00
|
|
|
nh_len = parse_ipv6hdr(skb, key);
|
2011-10-26 06:26:31 +04:00
|
|
|
if (unlikely(nh_len < 0)) {
|
2015-08-29 03:02:21 +03:00
|
|
|
switch (nh_len) {
|
|
|
|
case -EINVAL:
|
|
|
|
memset(&key->ip, 0, sizeof(key->ip));
|
|
|
|
memset(&key->ipv6.addr, 0, sizeof(key->ipv6.addr));
|
2020-08-24 01:36:59 +03:00
|
|
|
fallthrough;
|
2015-08-29 03:02:21 +03:00
|
|
|
case -EPROTO:
|
2011-10-26 06:26:31 +04:00
|
|
|
skb->transport_header = skb->network_header;
|
2013-08-08 07:01:00 +04:00
|
|
|
error = 0;
|
2015-08-29 03:02:21 +03:00
|
|
|
break;
|
|
|
|
default:
|
2011-10-26 06:26:31 +04:00
|
|
|
error = nh_len;
|
2013-08-08 07:01:00 +04:00
|
|
|
}
|
|
|
|
return error;
|
2011-10-26 06:26:31 +04:00
|
|
|
}
|
|
|
|
|
2019-08-27 17:58:10 +03:00
|
|
|
if (key->ip.frag == OVS_FRAG_TYPE_LATER) {
|
|
|
|
memset(&key->tp, 0, sizeof(key->tp));
|
2013-08-08 07:01:00 +04:00
|
|
|
return 0;
|
2019-08-27 17:58:10 +03:00
|
|
|
}
|
net: accept UFO datagrams from tuntap and packet
Tuntap and similar devices can inject GSO packets. Accept type
VIRTIO_NET_HDR_GSO_UDP, even though not generating UFO natively.
Processes are expected to use feature negotiation such as TUNSETOFFLOAD
to detect supported offload types and refrain from injecting other
packets. This process breaks down with live migration: guest kernels
do not renegotiate flags, so destination hosts need to expose all
features that the source host does.
Partially revert the UFO removal from 182e0b6b5846~1..d9d30adf5677.
This patch introduces nearly(*) no new code to simplify verification.
It brings back verbatim tuntap UFO negotiation, VIRTIO_NET_HDR_GSO_UDP
insertion and software UFO segmentation.
It does not reinstate protocol stack support, hardware offload
(NETIF_F_UFO), SKB_GSO_UDP tunneling in SKB_GSO_SOFTWARE or reception
of VIRTIO_NET_HDR_GSO_UDP packets in tuntap.
To support SKB_GSO_UDP reappearing in the stack, also reinstate
logic in act_csum and openvswitch. Achieve equivalence with v4.13 HEAD
by squashing in commit 939912216fa8 ("net: skb_needs_check() removes
CHECKSUM_UNNECESSARY check for tx.") and reverting commit 8d63bee643f1
("net: avoid skb_warn_bad_offload false positives on UFO").
(*) To avoid having to bring back skb_shinfo(skb)->ip6_frag_id,
ipv6_proxy_select_ident is changed to return a __be32 and this is
assigned directly to the frag_hdr. Also, SKB_GSO_UDP is inserted
at the end of the enum to minimize code churn.
Tested
Booted a v4.13 guest kernel with QEMU. On a host kernel before this
patch `ethtool -k eth0` shows UFO disabled. After the patch, it is
enabled, same as on a v4.13 host kernel.
A UFO packet sent from the guest appears on the tap device:
host:
nc -l -p -u 8000 &
tcpdump -n -i tap0
guest:
dd if=/dev/zero of=payload.txt bs=1 count=2000
nc -u 192.16.1.1 8000 < payload.txt
Direct tap to tap transmission of VIRTIO_NET_HDR_GSO_UDP succeeds,
packets arriving fragmented:
./with_tap_pair.sh ./tap_send_ufo tap0 tap1
(from https://github.com/wdebruij/kerneltools/tree/master/tests)
Changes
v1 -> v2
- simplified set_offload change (review comment)
- documented test procedure
Link: http://lkml.kernel.org/r/<CAF=yD-LuUeDuL9YWPJD9ykOZ0QCjNeznPDr6whqZ9NGMNF12Mw@mail.gmail.com>
Fixes: fb652fdfe837 ("macvlan/macvtap: Remove NETIF_F_UFO advertisement.")
Reported-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-21 18:22:25 +03:00
|
|
|
if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP)
|
|
|
|
key->ip.frag = OVS_FRAG_TYPE_FIRST;
|
|
|
|
|
2011-10-26 06:26:31 +04:00
|
|
|
/* Transport layer. */
|
|
|
|
if (key->ip.proto == NEXTHDR_TCP) {
|
|
|
|
if (tcphdr_ok(skb)) {
|
|
|
|
struct tcphdr *tcp = tcp_hdr(skb);
|
2014-05-05 20:54:49 +04:00
|
|
|
key->tp.src = tcp->source;
|
|
|
|
key->tp.dst = tcp->dest;
|
|
|
|
key->tp.flags = TCP_FLAGS_BE16(tcp);
|
2014-10-04 02:35:29 +04:00
|
|
|
} else {
|
|
|
|
memset(&key->tp, 0, sizeof(key->tp));
|
2011-10-26 06:26:31 +04:00
|
|
|
}
|
|
|
|
} else if (key->ip.proto == NEXTHDR_UDP) {
|
|
|
|
if (udphdr_ok(skb)) {
|
|
|
|
struct udphdr *udp = udp_hdr(skb);
|
2014-05-05 20:54:49 +04:00
|
|
|
key->tp.src = udp->source;
|
|
|
|
key->tp.dst = udp->dest;
|
2014-10-04 02:35:29 +04:00
|
|
|
} else {
|
|
|
|
memset(&key->tp, 0, sizeof(key->tp));
|
2011-10-26 06:26:31 +04:00
|
|
|
}
|
2013-08-22 23:30:48 +04:00
|
|
|
} else if (key->ip.proto == NEXTHDR_SCTP) {
|
|
|
|
if (sctphdr_ok(skb)) {
|
|
|
|
struct sctphdr *sctp = sctp_hdr(skb);
|
2014-05-05 20:54:49 +04:00
|
|
|
key->tp.src = sctp->source;
|
|
|
|
key->tp.dst = sctp->dest;
|
2014-10-04 02:35:29 +04:00
|
|
|
} else {
|
|
|
|
memset(&key->tp, 0, sizeof(key->tp));
|
2013-08-22 23:30:48 +04:00
|
|
|
}
|
2011-10-26 06:26:31 +04:00
|
|
|
} else if (key->ip.proto == NEXTHDR_ICMP) {
|
|
|
|
if (icmp6hdr_ok(skb)) {
|
2013-08-08 07:01:00 +04:00
|
|
|
error = parse_icmpv6(skb, key, nh_len);
|
|
|
|
if (error)
|
|
|
|
return error;
|
2014-10-04 02:35:29 +04:00
|
|
|
} else {
|
|
|
|
memset(&key->tp, 0, sizeof(key->tp));
|
2011-10-26 06:26:31 +04:00
|
|
|
}
|
|
|
|
}
|
2017-11-07 16:07:02 +03:00
|
|
|
} else if (key->eth.type == htons(ETH_P_NSH)) {
|
|
|
|
error = parse_nsh(skb, key);
|
|
|
|
if (error)
|
|
|
|
return error;
|
2011-10-26 06:26:31 +04:00
|
|
|
}
|
2013-08-08 07:01:00 +04:00
|
|
|
return 0;
|
2011-10-26 06:26:31 +04:00
|
|
|
}
|
2014-09-16 06:20:31 +04:00
|
|
|
|
2019-08-27 17:58:09 +03:00
|
|
|
/**
|
|
|
|
* key_extract - extracts a flow key from an Ethernet frame.
|
|
|
|
* @skb: sk_buff that contains the frame, with skb->data pointing to the
|
|
|
|
* Ethernet header
|
|
|
|
* @key: output flow key
|
|
|
|
*
|
|
|
|
* The caller must ensure that skb->len >= ETH_HLEN.
|
|
|
|
*
|
|
|
|
* Initializes @skb header fields as follows:
|
|
|
|
*
|
|
|
|
* - skb->mac_header: the L2 header.
|
|
|
|
*
|
|
|
|
* - skb->network_header: just past the L2 header, or just past the
|
|
|
|
* VLAN header, to the first byte of the L2 payload.
|
|
|
|
*
|
|
|
|
* - skb->transport_header: If key->eth.type is ETH_P_IP or ETH_P_IPV6
|
|
|
|
* on output, then just past the IP header, if one is present and
|
|
|
|
* of a correct length, otherwise the same as skb->network_header.
|
|
|
|
* For other key->eth.type values it is left untouched.
|
|
|
|
*
|
|
|
|
* - skb->protocol: the type of the data starting at skb->network_header.
|
|
|
|
* Equals to key->eth.type.
|
2021-08-08 22:08:34 +03:00
|
|
|
*
|
|
|
|
* Return: %0 if successful, otherwise a negative errno value.
|
2019-08-27 17:58:09 +03:00
|
|
|
*/
|
|
|
|
static int key_extract(struct sk_buff *skb, struct sw_flow_key *key)
|
|
|
|
{
|
|
|
|
struct ethhdr *eth;
|
|
|
|
|
|
|
|
/* Flags are always used as part of stats */
|
|
|
|
key->tp.flags = 0;
|
|
|
|
|
|
|
|
skb_reset_mac_header(skb);
|
|
|
|
|
|
|
|
/* Link layer. */
|
|
|
|
clear_vlan(key);
|
|
|
|
if (ovs_key_mac_proto(key) == MAC_PROTO_NONE) {
|
|
|
|
if (unlikely(eth_type_vlan(skb->protocol)))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
skb_reset_network_header(skb);
|
|
|
|
key->eth.type = skb->protocol;
|
|
|
|
} else {
|
|
|
|
eth = eth_hdr(skb);
|
|
|
|
ether_addr_copy(key->eth.src, eth->h_source);
|
|
|
|
ether_addr_copy(key->eth.dst, eth->h_dest);
|
|
|
|
|
|
|
|
__skb_pull(skb, 2 * ETH_ALEN);
|
|
|
|
/* We are going to push all headers that we pull, so no need to
|
|
|
|
* update skb->csum here.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (unlikely(parse_vlan(skb, key)))
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
key->eth.type = parse_ethertype(skb);
|
|
|
|
if (unlikely(key->eth.type == htons(0)))
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
/* Multiple tagged packets need to retain TPID to satisfy
|
|
|
|
* skb_vlan_pop(), which will later shift the ethertype into
|
|
|
|
* skb->protocol.
|
|
|
|
*/
|
|
|
|
if (key->eth.cvlan.tci & htons(VLAN_CFI_MASK))
|
|
|
|
skb->protocol = key->eth.cvlan.tpid;
|
|
|
|
else
|
|
|
|
skb->protocol = key->eth.type;
|
|
|
|
|
|
|
|
skb_reset_network_header(skb);
|
|
|
|
__skb_push(skb, skb->data - skb_mac_header(skb));
|
|
|
|
}
|
|
|
|
|
|
|
|
skb_reset_mac_len(skb);
|
|
|
|
|
|
|
|
/* Fill out L3/L4 key info, if any */
|
|
|
|
return key_extract_l3l4(skb, key);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* In the case of conntrack fragment handling it expects L3 headers,
|
|
|
|
* add a helper.
|
|
|
|
*/
|
|
|
|
int ovs_flow_key_update_l3l4(struct sk_buff *skb, struct sw_flow_key *key)
|
|
|
|
{
|
|
|
|
return key_extract_l3l4(skb, key);
|
|
|
|
}
|
|
|
|
|
2014-09-16 06:37:25 +04:00
|
|
|
int ovs_flow_key_update(struct sk_buff *skb, struct sw_flow_key *key)
|
|
|
|
{
|
2017-03-30 22:36:03 +03:00
|
|
|
int res;
|
|
|
|
|
|
|
|
res = key_extract(skb, key);
|
|
|
|
if (!res)
|
|
|
|
key->mac_proto &= ~SW_FLOW_KEY_INVALID;
|
|
|
|
|
|
|
|
return res;
|
2014-09-16 06:37:25 +04:00
|
|
|
}
|
|
|
|
|
2016-11-10 18:28:21 +03:00
|
|
|
static int key_extract_mac_proto(struct sk_buff *skb)
|
|
|
|
{
|
|
|
|
switch (skb->dev->type) {
|
|
|
|
case ARPHRD_ETHER:
|
|
|
|
return MAC_PROTO_ETHERNET;
|
|
|
|
case ARPHRD_NONE:
|
|
|
|
if (skb->protocol == htons(ETH_P_TEB))
|
|
|
|
return MAC_PROTO_ETHERNET;
|
|
|
|
return MAC_PROTO_NONE;
|
|
|
|
}
|
|
|
|
WARN_ON_ONCE(1);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2015-07-21 11:43:54 +03:00
|
|
|
int ovs_flow_key_extract(const struct ip_tunnel_info *tun_info,
|
2014-09-16 06:28:44 +04:00
|
|
|
struct sk_buff *skb, struct sw_flow_key *key)
|
2014-09-16 06:20:31 +04:00
|
|
|
{
|
net: openvswitch: Set OvS recirc_id from tc chain index
Offloaded OvS datapath rules are translated one to one to tc rules,
for example the following simplified OvS rule:
recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2)
Will be translated to the following tc rule:
$ tc filter add dev dev1 ingress \
prio 1 chain 0 proto ip \
flower tcp ct_state -trk \
action ct pipe \
action goto chain 2
Received packets will first travel though tc, and if they aren't stolen
by it, like in the above rule, they will continue to OvS datapath.
Since we already did some actions (action ct in this case) which might
modify the packets, and updated action stats, we would like to continue
the proccessing with the correct recirc_id in OvS (here recirc_id(2))
where we left off.
To support this, introduce a new skb extension for tc, which
will be used for translating tc chain to ovs recirc_id to
handle these miss cases. Last tc chain index will be set
by tc goto chain action and read by OvS datapath.
Signed-off-by: Paul Blakey <paulb@mellanox.com>
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-04 16:56:37 +03:00
|
|
|
#if IS_ENABLED(CONFIG_NET_TC_SKB_EXT)
|
|
|
|
struct tc_skb_ext *tc_ext;
|
|
|
|
#endif
|
2022-01-06 18:38:04 +03:00
|
|
|
bool post_ct = false, post_ct_snat = false, post_ct_dnat = false;
|
openvswitch: Add original direction conntrack tuple to sw_flow_key.
Add the fields of the conntrack original direction 5-tuple to struct
sw_flow_key. The new fields are initially marked as non-existent, and
are populated whenever a conntrack action is executed and either finds
or generates a conntrack entry. This means that these fields exist
for all packets that were not rejected by conntrack as untrackable.
The original tuple fields in the sw_flow_key are filled from the
original direction tuple of the conntrack entry relating to the
current packet, or from the original direction tuple of the master
conntrack entry, if the current conntrack entry has a master.
Generally, expected connections of connections having an assigned
helper (e.g., FTP), have a master conntrack entry.
The main purpose of the new conntrack original tuple fields is to
allow matching on them for policy decision purposes, with the premise
that the admissibility of tracked connections reply packets (as well
as original direction packets), and both direction packets of any
related connections may be based on ACL rules applying to the master
connection's original direction 5-tuple. This also makes it easier to
make policy decisions when the actual packet headers might have been
transformed by NAT, as the original direction 5-tuple represents the
packet headers before any such transformation.
When using the original direction 5-tuple the admissibility of return
and/or related packets need not be based on the mere existence of a
conntrack entry, allowing separation of admission policy from the
established conntrack state. While existence of a conntrack entry is
required for admission of the return or related packets, policy
changes can render connections that were initially admitted to be
rejected or dropped afterwards. If the admission of the return and
related packets was based on mere conntrack state (e.g., connection
being in an established state), a policy change that would make the
connection rejected or dropped would need to find and delete all
conntrack entries affected by such a change. When using the original
direction 5-tuple matching the affected conntrack entries can be
allowed to time out instead, as the established state of the
connection would not need to be the basis for packet admission any
more.
It should be noted that the directionality of related connections may
be the same or different than that of the master connection, and
neither the original direction 5-tuple nor the conntrack state bits
carry this information. If needed, the directionality of the master
connection can be stored in master's conntrack mark or labels, which
are automatically inherited by the expected related connections.
The fact that neither ARP nor ND packets are trackable by conntrack
allows mutual exclusion between ARP/ND and the new conntrack original
tuple fields. Hence, the IP addresses are overlaid in union with ARP
and ND fields. This allows the sw_flow_key to not grow much due to
this patch, but it also means that we must be careful to never use the
new key fields with ARP or ND packets. ARP is easy to distinguish and
keep mutually exclusive based on the ethernet type, but ND being an
ICMPv6 protocol requires a bit more attention.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Joe Stringer <joe@ovn.org>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-09 22:21:59 +03:00
|
|
|
int res, err;
|
2021-12-14 20:24:35 +03:00
|
|
|
u16 zone = 0;
|
2016-11-10 18:28:21 +03:00
|
|
|
|
2014-09-16 06:20:31 +04:00
|
|
|
/* Extract metadata from packet. */
|
2014-10-04 02:35:33 +04:00
|
|
|
if (tun_info) {
|
2015-10-05 14:09:46 +03:00
|
|
|
key->tun_proto = ip_tunnel_info_af(tun_info);
|
2015-07-21 11:43:54 +03:00
|
|
|
memcpy(&key->tun_key, &tun_info->key, sizeof(key->tun_key));
|
2014-10-04 02:35:33 +04:00
|
|
|
|
2015-08-31 04:09:38 +03:00
|
|
|
if (tun_info->options_len) {
|
2014-10-04 02:35:33 +04:00
|
|
|
BUILD_BUG_ON((1 << (sizeof(tun_info->options_len) *
|
|
|
|
8)) - 1
|
|
|
|
> sizeof(key->tun_opts));
|
2015-08-31 04:09:38 +03:00
|
|
|
|
|
|
|
ip_tunnel_info_opts_get(TUN_METADATA_OPTS(key, tun_info->options_len),
|
|
|
|
tun_info);
|
2014-10-04 02:35:33 +04:00
|
|
|
key->tun_opts_len = tun_info->options_len;
|
|
|
|
} else {
|
|
|
|
key->tun_opts_len = 0;
|
|
|
|
}
|
|
|
|
} else {
|
2015-10-05 14:09:46 +03:00
|
|
|
key->tun_proto = 0;
|
2014-10-04 02:35:33 +04:00
|
|
|
key->tun_opts_len = 0;
|
2014-10-04 02:35:29 +04:00
|
|
|
memset(&key->tun_key, 0, sizeof(key->tun_key));
|
2014-10-04 02:35:33 +04:00
|
|
|
}
|
2014-09-16 06:20:31 +04:00
|
|
|
|
|
|
|
key->phy.priority = skb->priority;
|
|
|
|
key->phy.in_port = OVS_CB(skb)->input_vport->port_no;
|
|
|
|
key->phy.skb_mark = skb->mark;
|
2014-10-04 02:35:29 +04:00
|
|
|
key->ovs_flow_hash = 0;
|
2016-11-10 18:28:21 +03:00
|
|
|
res = key_extract_mac_proto(skb);
|
|
|
|
if (res < 0)
|
|
|
|
return res;
|
|
|
|
key->mac_proto = res;
|
net: openvswitch: Set OvS recirc_id from tc chain index
Offloaded OvS datapath rules are translated one to one to tc rules,
for example the following simplified OvS rule:
recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2)
Will be translated to the following tc rule:
$ tc filter add dev dev1 ingress \
prio 1 chain 0 proto ip \
flower tcp ct_state -trk \
action ct pipe \
action goto chain 2
Received packets will first travel though tc, and if they aren't stolen
by it, like in the above rule, they will continue to OvS datapath.
Since we already did some actions (action ct in this case) which might
modify the packets, and updated action stats, we would like to continue
the proccessing with the correct recirc_id in OvS (here recirc_id(2))
where we left off.
To support this, introduce a new skb extension for tc, which
will be used for translating tc chain to ovs recirc_id to
handle these miss cases. Last tc chain index will be set
by tc goto chain action and read by OvS datapath.
Signed-off-by: Paul Blakey <paulb@mellanox.com>
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-04 16:56:37 +03:00
|
|
|
|
|
|
|
#if IS_ENABLED(CONFIG_NET_TC_SKB_EXT)
|
2022-02-03 11:44:30 +03:00
|
|
|
if (tc_skb_ext_tc_enabled()) {
|
net: openvswitch: Set OvS recirc_id from tc chain index
Offloaded OvS datapath rules are translated one to one to tc rules,
for example the following simplified OvS rule:
recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2)
Will be translated to the following tc rule:
$ tc filter add dev dev1 ingress \
prio 1 chain 0 proto ip \
flower tcp ct_state -trk \
action ct pipe \
action goto chain 2
Received packets will first travel though tc, and if they aren't stolen
by it, like in the above rule, they will continue to OvS datapath.
Since we already did some actions (action ct in this case) which might
modify the packets, and updated action stats, we would like to continue
the proccessing with the correct recirc_id in OvS (here recirc_id(2))
where we left off.
To support this, introduce a new skb extension for tc, which
will be used for translating tc chain to ovs recirc_id to
handle these miss cases. Last tc chain index will be set
by tc goto chain action and read by OvS datapath.
Signed-off-by: Paul Blakey <paulb@mellanox.com>
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-04 16:56:37 +03:00
|
|
|
tc_ext = skb_ext_find(skb, TC_SKB_EXT);
|
|
|
|
key->recirc_id = tc_ext ? tc_ext->chain : 0;
|
2020-07-31 05:45:01 +03:00
|
|
|
OVS_CB(skb)->mru = tc_ext ? tc_ext->mru : 0;
|
2021-03-16 11:33:54 +03:00
|
|
|
post_ct = tc_ext ? tc_ext->post_ct : false;
|
2022-01-06 18:38:04 +03:00
|
|
|
post_ct_snat = post_ct ? tc_ext->post_ct_snat : false;
|
|
|
|
post_ct_dnat = post_ct ? tc_ext->post_ct_dnat : false;
|
2021-12-14 20:24:35 +03:00
|
|
|
zone = post_ct ? tc_ext->zone : 0;
|
net: openvswitch: Set OvS recirc_id from tc chain index
Offloaded OvS datapath rules are translated one to one to tc rules,
for example the following simplified OvS rule:
recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2)
Will be translated to the following tc rule:
$ tc filter add dev dev1 ingress \
prio 1 chain 0 proto ip \
flower tcp ct_state -trk \
action ct pipe \
action goto chain 2
Received packets will first travel though tc, and if they aren't stolen
by it, like in the above rule, they will continue to OvS datapath.
Since we already did some actions (action ct in this case) which might
modify the packets, and updated action stats, we would like to continue
the proccessing with the correct recirc_id in OvS (here recirc_id(2))
where we left off.
To support this, introduce a new skb extension for tc, which
will be used for translating tc chain to ovs recirc_id to
handle these miss cases. Last tc chain index will be set
by tc goto chain action and read by OvS datapath.
Signed-off-by: Paul Blakey <paulb@mellanox.com>
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-04 16:56:37 +03:00
|
|
|
} else {
|
|
|
|
key->recirc_id = 0;
|
|
|
|
}
|
|
|
|
#else
|
2014-10-04 02:35:29 +04:00
|
|
|
key->recirc_id = 0;
|
net: openvswitch: Set OvS recirc_id from tc chain index
Offloaded OvS datapath rules are translated one to one to tc rules,
for example the following simplified OvS rule:
recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2)
Will be translated to the following tc rule:
$ tc filter add dev dev1 ingress \
prio 1 chain 0 proto ip \
flower tcp ct_state -trk \
action ct pipe \
action goto chain 2
Received packets will first travel though tc, and if they aren't stolen
by it, like in the above rule, they will continue to OvS datapath.
Since we already did some actions (action ct in this case) which might
modify the packets, and updated action stats, we would like to continue
the proccessing with the correct recirc_id in OvS (here recirc_id(2))
where we left off.
To support this, introduce a new skb extension for tc, which
will be used for translating tc chain to ovs recirc_id to
handle these miss cases. Last tc chain index will be set
by tc goto chain action and read by OvS datapath.
Signed-off-by: Paul Blakey <paulb@mellanox.com>
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-04 16:56:37 +03:00
|
|
|
#endif
|
2014-10-04 02:35:29 +04:00
|
|
|
|
openvswitch: Add original direction conntrack tuple to sw_flow_key.
Add the fields of the conntrack original direction 5-tuple to struct
sw_flow_key. The new fields are initially marked as non-existent, and
are populated whenever a conntrack action is executed and either finds
or generates a conntrack entry. This means that these fields exist
for all packets that were not rejected by conntrack as untrackable.
The original tuple fields in the sw_flow_key are filled from the
original direction tuple of the conntrack entry relating to the
current packet, or from the original direction tuple of the master
conntrack entry, if the current conntrack entry has a master.
Generally, expected connections of connections having an assigned
helper (e.g., FTP), have a master conntrack entry.
The main purpose of the new conntrack original tuple fields is to
allow matching on them for policy decision purposes, with the premise
that the admissibility of tracked connections reply packets (as well
as original direction packets), and both direction packets of any
related connections may be based on ACL rules applying to the master
connection's original direction 5-tuple. This also makes it easier to
make policy decisions when the actual packet headers might have been
transformed by NAT, as the original direction 5-tuple represents the
packet headers before any such transformation.
When using the original direction 5-tuple the admissibility of return
and/or related packets need not be based on the mere existence of a
conntrack entry, allowing separation of admission policy from the
established conntrack state. While existence of a conntrack entry is
required for admission of the return or related packets, policy
changes can render connections that were initially admitted to be
rejected or dropped afterwards. If the admission of the return and
related packets was based on mere conntrack state (e.g., connection
being in an established state), a policy change that would make the
connection rejected or dropped would need to find and delete all
conntrack entries affected by such a change. When using the original
direction 5-tuple matching the affected conntrack entries can be
allowed to time out instead, as the established state of the
connection would not need to be the basis for packet admission any
more.
It should be noted that the directionality of related connections may
be the same or different than that of the master connection, and
neither the original direction 5-tuple nor the conntrack state bits
carry this information. If needed, the directionality of the master
connection can be stored in master's conntrack mark or labels, which
are automatically inherited by the expected related connections.
The fact that neither ARP nor ND packets are trackable by conntrack
allows mutual exclusion between ARP/ND and the new conntrack original
tuple fields. Hence, the IP addresses are overlaid in union with ARP
and ND fields. This allows the sw_flow_key to not grow much due to
this patch, but it also means that we must be careful to never use the
new key fields with ARP or ND packets. ARP is easy to distinguish and
keep mutually exclusive based on the ethernet type, but ND being an
ICMPv6 protocol requires a bit more attention.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Joe Stringer <joe@ovn.org>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-09 22:21:59 +03:00
|
|
|
err = key_extract(skb, key);
|
2021-12-14 20:24:35 +03:00
|
|
|
if (!err) {
|
2021-03-16 11:33:54 +03:00
|
|
|
ovs_ct_fill_key(skb, key, post_ct); /* Must be after key_extract(). */
|
2022-01-06 18:38:04 +03:00
|
|
|
if (post_ct) {
|
|
|
|
if (!skb_get_nfct(skb)) {
|
|
|
|
key->ct_zone = zone;
|
|
|
|
} else {
|
|
|
|
if (!post_ct_dnat)
|
|
|
|
key->ct_state &= ~OVS_CS_F_DST_NAT;
|
|
|
|
if (!post_ct_snat)
|
|
|
|
key->ct_state &= ~OVS_CS_F_SRC_NAT;
|
|
|
|
}
|
|
|
|
}
|
2021-12-14 20:24:35 +03:00
|
|
|
}
|
openvswitch: Add original direction conntrack tuple to sw_flow_key.
Add the fields of the conntrack original direction 5-tuple to struct
sw_flow_key. The new fields are initially marked as non-existent, and
are populated whenever a conntrack action is executed and either finds
or generates a conntrack entry. This means that these fields exist
for all packets that were not rejected by conntrack as untrackable.
The original tuple fields in the sw_flow_key are filled from the
original direction tuple of the conntrack entry relating to the
current packet, or from the original direction tuple of the master
conntrack entry, if the current conntrack entry has a master.
Generally, expected connections of connections having an assigned
helper (e.g., FTP), have a master conntrack entry.
The main purpose of the new conntrack original tuple fields is to
allow matching on them for policy decision purposes, with the premise
that the admissibility of tracked connections reply packets (as well
as original direction packets), and both direction packets of any
related connections may be based on ACL rules applying to the master
connection's original direction 5-tuple. This also makes it easier to
make policy decisions when the actual packet headers might have been
transformed by NAT, as the original direction 5-tuple represents the
packet headers before any such transformation.
When using the original direction 5-tuple the admissibility of return
and/or related packets need not be based on the mere existence of a
conntrack entry, allowing separation of admission policy from the
established conntrack state. While existence of a conntrack entry is
required for admission of the return or related packets, policy
changes can render connections that were initially admitted to be
rejected or dropped afterwards. If the admission of the return and
related packets was based on mere conntrack state (e.g., connection
being in an established state), a policy change that would make the
connection rejected or dropped would need to find and delete all
conntrack entries affected by such a change. When using the original
direction 5-tuple matching the affected conntrack entries can be
allowed to time out instead, as the established state of the
connection would not need to be the basis for packet admission any
more.
It should be noted that the directionality of related connections may
be the same or different than that of the master connection, and
neither the original direction 5-tuple nor the conntrack state bits
carry this information. If needed, the directionality of the master
connection can be stored in master's conntrack mark or labels, which
are automatically inherited by the expected related connections.
The fact that neither ARP nor ND packets are trackable by conntrack
allows mutual exclusion between ARP/ND and the new conntrack original
tuple fields. Hence, the IP addresses are overlaid in union with ARP
and ND fields. This allows the sw_flow_key to not grow much due to
this patch, but it also means that we must be careful to never use the
new key fields with ARP or ND packets. ARP is easy to distinguish and
keep mutually exclusive based on the ethernet type, but ND being an
ICMPv6 protocol requires a bit more attention.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Joe Stringer <joe@ovn.org>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-09 22:21:59 +03:00
|
|
|
return err;
|
2014-09-16 06:20:31 +04:00
|
|
|
}
|
|
|
|
|
2015-08-26 21:31:52 +03:00
|
|
|
int ovs_flow_key_extract_userspace(struct net *net, const struct nlattr *attr,
|
2014-09-16 06:20:31 +04:00
|
|
|
struct sk_buff *skb,
|
2014-11-06 18:03:05 +03:00
|
|
|
struct sw_flow_key *key, bool log)
|
2014-09-16 06:20:31 +04:00
|
|
|
{
|
openvswitch: Add original direction conntrack tuple to sw_flow_key.
Add the fields of the conntrack original direction 5-tuple to struct
sw_flow_key. The new fields are initially marked as non-existent, and
are populated whenever a conntrack action is executed and either finds
or generates a conntrack entry. This means that these fields exist
for all packets that were not rejected by conntrack as untrackable.
The original tuple fields in the sw_flow_key are filled from the
original direction tuple of the conntrack entry relating to the
current packet, or from the original direction tuple of the master
conntrack entry, if the current conntrack entry has a master.
Generally, expected connections of connections having an assigned
helper (e.g., FTP), have a master conntrack entry.
The main purpose of the new conntrack original tuple fields is to
allow matching on them for policy decision purposes, with the premise
that the admissibility of tracked connections reply packets (as well
as original direction packets), and both direction packets of any
related connections may be based on ACL rules applying to the master
connection's original direction 5-tuple. This also makes it easier to
make policy decisions when the actual packet headers might have been
transformed by NAT, as the original direction 5-tuple represents the
packet headers before any such transformation.
When using the original direction 5-tuple the admissibility of return
and/or related packets need not be based on the mere existence of a
conntrack entry, allowing separation of admission policy from the
established conntrack state. While existence of a conntrack entry is
required for admission of the return or related packets, policy
changes can render connections that were initially admitted to be
rejected or dropped afterwards. If the admission of the return and
related packets was based on mere conntrack state (e.g., connection
being in an established state), a policy change that would make the
connection rejected or dropped would need to find and delete all
conntrack entries affected by such a change. When using the original
direction 5-tuple matching the affected conntrack entries can be
allowed to time out instead, as the established state of the
connection would not need to be the basis for packet admission any
more.
It should be noted that the directionality of related connections may
be the same or different than that of the master connection, and
neither the original direction 5-tuple nor the conntrack state bits
carry this information. If needed, the directionality of the master
connection can be stored in master's conntrack mark or labels, which
are automatically inherited by the expected related connections.
The fact that neither ARP nor ND packets are trackable by conntrack
allows mutual exclusion between ARP/ND and the new conntrack original
tuple fields. Hence, the IP addresses are overlaid in union with ARP
and ND fields. This allows the sw_flow_key to not grow much due to
this patch, but it also means that we must be careful to never use the
new key fields with ARP or ND packets. ARP is easy to distinguish and
keep mutually exclusive based on the ethernet type, but ND being an
ICMPv6 protocol requires a bit more attention.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Joe Stringer <joe@ovn.org>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-09 22:21:59 +03:00
|
|
|
const struct nlattr *a[OVS_KEY_ATTR_MAX + 1];
|
|
|
|
u64 attrs = 0;
|
2014-09-16 06:20:31 +04:00
|
|
|
int err;
|
|
|
|
|
openvswitch: Add original direction conntrack tuple to sw_flow_key.
Add the fields of the conntrack original direction 5-tuple to struct
sw_flow_key. The new fields are initially marked as non-existent, and
are populated whenever a conntrack action is executed and either finds
or generates a conntrack entry. This means that these fields exist
for all packets that were not rejected by conntrack as untrackable.
The original tuple fields in the sw_flow_key are filled from the
original direction tuple of the conntrack entry relating to the
current packet, or from the original direction tuple of the master
conntrack entry, if the current conntrack entry has a master.
Generally, expected connections of connections having an assigned
helper (e.g., FTP), have a master conntrack entry.
The main purpose of the new conntrack original tuple fields is to
allow matching on them for policy decision purposes, with the premise
that the admissibility of tracked connections reply packets (as well
as original direction packets), and both direction packets of any
related connections may be based on ACL rules applying to the master
connection's original direction 5-tuple. This also makes it easier to
make policy decisions when the actual packet headers might have been
transformed by NAT, as the original direction 5-tuple represents the
packet headers before any such transformation.
When using the original direction 5-tuple the admissibility of return
and/or related packets need not be based on the mere existence of a
conntrack entry, allowing separation of admission policy from the
established conntrack state. While existence of a conntrack entry is
required for admission of the return or related packets, policy
changes can render connections that were initially admitted to be
rejected or dropped afterwards. If the admission of the return and
related packets was based on mere conntrack state (e.g., connection
being in an established state), a policy change that would make the
connection rejected or dropped would need to find and delete all
conntrack entries affected by such a change. When using the original
direction 5-tuple matching the affected conntrack entries can be
allowed to time out instead, as the established state of the
connection would not need to be the basis for packet admission any
more.
It should be noted that the directionality of related connections may
be the same or different than that of the master connection, and
neither the original direction 5-tuple nor the conntrack state bits
carry this information. If needed, the directionality of the master
connection can be stored in master's conntrack mark or labels, which
are automatically inherited by the expected related connections.
The fact that neither ARP nor ND packets are trackable by conntrack
allows mutual exclusion between ARP/ND and the new conntrack original
tuple fields. Hence, the IP addresses are overlaid in union with ARP
and ND fields. This allows the sw_flow_key to not grow much due to
this patch, but it also means that we must be careful to never use the
new key fields with ARP or ND packets. ARP is easy to distinguish and
keep mutually exclusive based on the ethernet type, but ND being an
ICMPv6 protocol requires a bit more attention.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Joe Stringer <joe@ovn.org>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-09 22:21:59 +03:00
|
|
|
err = parse_flow_nlattrs(attr, a, &attrs, log);
|
|
|
|
if (err)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2014-09-16 06:20:31 +04:00
|
|
|
/* Extract metadata from netlink attributes. */
|
openvswitch: Add original direction conntrack tuple to sw_flow_key.
Add the fields of the conntrack original direction 5-tuple to struct
sw_flow_key. The new fields are initially marked as non-existent, and
are populated whenever a conntrack action is executed and either finds
or generates a conntrack entry. This means that these fields exist
for all packets that were not rejected by conntrack as untrackable.
The original tuple fields in the sw_flow_key are filled from the
original direction tuple of the conntrack entry relating to the
current packet, or from the original direction tuple of the master
conntrack entry, if the current conntrack entry has a master.
Generally, expected connections of connections having an assigned
helper (e.g., FTP), have a master conntrack entry.
The main purpose of the new conntrack original tuple fields is to
allow matching on them for policy decision purposes, with the premise
that the admissibility of tracked connections reply packets (as well
as original direction packets), and both direction packets of any
related connections may be based on ACL rules applying to the master
connection's original direction 5-tuple. This also makes it easier to
make policy decisions when the actual packet headers might have been
transformed by NAT, as the original direction 5-tuple represents the
packet headers before any such transformation.
When using the original direction 5-tuple the admissibility of return
and/or related packets need not be based on the mere existence of a
conntrack entry, allowing separation of admission policy from the
established conntrack state. While existence of a conntrack entry is
required for admission of the return or related packets, policy
changes can render connections that were initially admitted to be
rejected or dropped afterwards. If the admission of the return and
related packets was based on mere conntrack state (e.g., connection
being in an established state), a policy change that would make the
connection rejected or dropped would need to find and delete all
conntrack entries affected by such a change. When using the original
direction 5-tuple matching the affected conntrack entries can be
allowed to time out instead, as the established state of the
connection would not need to be the basis for packet admission any
more.
It should be noted that the directionality of related connections may
be the same or different than that of the master connection, and
neither the original direction 5-tuple nor the conntrack state bits
carry this information. If needed, the directionality of the master
connection can be stored in master's conntrack mark or labels, which
are automatically inherited by the expected related connections.
The fact that neither ARP nor ND packets are trackable by conntrack
allows mutual exclusion between ARP/ND and the new conntrack original
tuple fields. Hence, the IP addresses are overlaid in union with ARP
and ND fields. This allows the sw_flow_key to not grow much due to
this patch, but it also means that we must be careful to never use the
new key fields with ARP or ND packets. ARP is easy to distinguish and
keep mutually exclusive based on the ethernet type, but ND being an
ICMPv6 protocol requires a bit more attention.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Joe Stringer <joe@ovn.org>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-09 22:21:59 +03:00
|
|
|
err = ovs_nla_get_flow_metadata(net, a, attrs, key, log);
|
2014-09-16 06:20:31 +04:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2016-12-26 19:31:27 +03:00
|
|
|
/* key_extract assumes that skb->protocol is set-up for
|
|
|
|
* layer 3 packets which is the case for other callers,
|
|
|
|
* in particular packets received from the network stack.
|
|
|
|
* Here the correct value can be set from the metadata
|
|
|
|
* extracted above.
|
|
|
|
* For L2 packet key eth type would be zero. skb protocol
|
|
|
|
* would be set to correct value later during key-extact.
|
|
|
|
*/
|
2016-11-10 18:28:21 +03:00
|
|
|
|
2016-12-26 19:31:27 +03:00
|
|
|
skb->protocol = key->eth.type;
|
openvswitch: Add original direction conntrack tuple to sw_flow_key.
Add the fields of the conntrack original direction 5-tuple to struct
sw_flow_key. The new fields are initially marked as non-existent, and
are populated whenever a conntrack action is executed and either finds
or generates a conntrack entry. This means that these fields exist
for all packets that were not rejected by conntrack as untrackable.
The original tuple fields in the sw_flow_key are filled from the
original direction tuple of the conntrack entry relating to the
current packet, or from the original direction tuple of the master
conntrack entry, if the current conntrack entry has a master.
Generally, expected connections of connections having an assigned
helper (e.g., FTP), have a master conntrack entry.
The main purpose of the new conntrack original tuple fields is to
allow matching on them for policy decision purposes, with the premise
that the admissibility of tracked connections reply packets (as well
as original direction packets), and both direction packets of any
related connections may be based on ACL rules applying to the master
connection's original direction 5-tuple. This also makes it easier to
make policy decisions when the actual packet headers might have been
transformed by NAT, as the original direction 5-tuple represents the
packet headers before any such transformation.
When using the original direction 5-tuple the admissibility of return
and/or related packets need not be based on the mere existence of a
conntrack entry, allowing separation of admission policy from the
established conntrack state. While existence of a conntrack entry is
required for admission of the return or related packets, policy
changes can render connections that were initially admitted to be
rejected or dropped afterwards. If the admission of the return and
related packets was based on mere conntrack state (e.g., connection
being in an established state), a policy change that would make the
connection rejected or dropped would need to find and delete all
conntrack entries affected by such a change. When using the original
direction 5-tuple matching the affected conntrack entries can be
allowed to time out instead, as the established state of the
connection would not need to be the basis for packet admission any
more.
It should be noted that the directionality of related connections may
be the same or different than that of the master connection, and
neither the original direction 5-tuple nor the conntrack state bits
carry this information. If needed, the directionality of the master
connection can be stored in master's conntrack mark or labels, which
are automatically inherited by the expected related connections.
The fact that neither ARP nor ND packets are trackable by conntrack
allows mutual exclusion between ARP/ND and the new conntrack original
tuple fields. Hence, the IP addresses are overlaid in union with ARP
and ND fields. This allows the sw_flow_key to not grow much due to
this patch, but it also means that we must be careful to never use the
new key fields with ARP or ND packets. ARP is easy to distinguish and
keep mutually exclusive based on the ethernet type, but ND being an
ICMPv6 protocol requires a bit more attention.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Joe Stringer <joe@ovn.org>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-09 22:21:59 +03:00
|
|
|
err = key_extract(skb, key);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
/* Check that we have conntrack original direction tuple metadata only
|
|
|
|
* for packets for which it makes sense. Otherwise the key may be
|
|
|
|
* corrupted due to overlapping key fields.
|
|
|
|
*/
|
|
|
|
if (attrs & (1 << OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4) &&
|
|
|
|
key->eth.type != htons(ETH_P_IP))
|
|
|
|
return -EINVAL;
|
|
|
|
if (attrs & (1 << OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV6) &&
|
|
|
|
(key->eth.type != htons(ETH_P_IPV6) ||
|
|
|
|
sw_flow_key_is_nd(key)))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return 0;
|
2014-09-16 06:20:31 +04:00
|
|
|
}
|