- Aug 25, 2017
-
-
Dan Carpenter authored
We never set the error code in this function. Fixes: eabf0fad ("net-next/hinic: Initialize api cmd resources") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
txq_reclaim() does the normal transmit queue reclamation and rxq_deinit() does the RX ring cleanup, none of these are packet drops, so use dev_consume_skb() for both locations. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
tg3_tx() does the normal packet TX completion, tigon3_dma_hwbug_workaround() and tg3_tso_bug() both need to allocate a new SKB that is suitable to workaround HW bugs, and finally tg3_free_rings() is doing ring cleanup. Use dev_consume_skb_any() for these 3 locations to be SKB drop monitor friendly. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Acked-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Jakub Sitnicki says: ==================== ipv6: Route ICMPv6 errors with the flow when ECMP in use This patch set is another take at making Path MTU Discovery work when server nodes are behind a router employing multipath routing in a load-balance or anycast setup (that is, when not every end-node can be reached by every path). The problem has been well described in RFC 7690 [1], but in short - in such setups ICMPv6 PTB errors are not guaranteed to be routed back to the server node that sent a reply that exceeds path MTU. The proposed solution is two-fold: (1) on the server side - reflect the Flow Label [2]. This can be done without modifying the application using a new per-netns sysctl knob that has been proposed independently of this patchset in the patch entitled "ipv6: Add sysctl for per namespace flow label reflection" [3]. (2) on the ECMP router - make the ipv6 routing subsystem look into the ICMPv6 error packets and compute the flow-hash from its payload, i.e. the offending packet that triggered the error. This is the same behavior as ipv4 stack has already. With both parts in place Path MTU Discovery can work past the ECMP router when using IPv6. [1] https://tools.ietf.org/html/rfc7690 [2] https://tools.ietf.org/html/draft-wang-6man-flow-label-reflection-01 [3] http://patchwork.ozlabs.org/patch/804870/ v1 -> v2: - don't use "extern" in external function declaration in header file - style change, put as many arguments as possible on the first line of a function call, and align consecutive lines to the first argument - expand the cover letter based on the feedback v2 -> v3: - switch to computing flow-hash using flow dissector to align with recent changes to multipath routing in ipv4 stack - add a sysctl knob for enabling flow label reflection per netns --- Testing has covered multipath routing of ICMPv6 PTB errors in forward and local output path in a simple use-case of an HTTP server sending a reply which is over the path MTU size [3]. I have also checked if the flows get evenly spread over multiple paths (i.e. if there are no regressions) [4]. [3] https://github.com/jsitnicki/tools/tree/master/net/tests/ecmp/pmtud [4] https://github.com/jsitnicki/tools/tree/master/net/tests/ecmp/load-balance ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jakub Sitnicki authored
Allow our callers to influence the choice of ECMP link by honoring the hash passed together with the flow info. This allows for special treatment of ICMP errors which we would like to route over the same path as the IPv6 datagram that triggered the error. Also go through rt6_multipath_hash(), in the usual case when we aren't dealing with an ICMP error, so that there is one central place where multipath hash is computed. Signed-off-by:
Jakub Sitnicki <jkbs@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jakub Sitnicki authored
Commit 644d0e65 ("ipv6 Use get_hash_from_flowi6 for rt6 hash") has turned rt6_info_hash_nhsfn() into a one-liner, so it no longer makes sense to keep it around. Also remove the accompanying comment that has become outdated. Signed-off-by:
Jakub Sitnicki <jkbs@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jakub Sitnicki authored
When forwarding or sending out an ICMPv6 error, look at the embedded packet that triggered the error and compute a flow hash over its headers. This let's us route the ICMP error together with the flow it belongs to when multipath (ECMP) routing is in use, which in turn makes Path MTU Discovery work in ECMP load-balanced or anycast setups (RFC 7690). Granted, end-hosts behind the ECMP router (aka servers) need to reflect the IPv6 Flow Label for PMTUD to work. The code is organized to be in parallel with ipv4 stack: ip_multipath_l3_keys -> ip6_multipath_l3_keys fib_multipath_hash -> rt6_multipath_hash Signed-off-by:
Jakub Sitnicki <jkbs@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jakub Sitnicki authored
Allow for functions that fill out the IPv6 flow info to also pass a hash computed over the skb contents. The hash value will drive the multipath routing decisions. This is intended for special treatment of ICMPv6 errors, where we would like to make a routing decision based on the flow identifying the offending IPv6 datagram that triggered the error, rather than the flow of the ICMP error itself. Signed-off-by:
Jakub Sitnicki <jkbs@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
One too many arguments compared to the non-stub version. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Fixes: ffd3cdcc ("devlink: Add support for dynamic table size") Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jakub Sitnicki authored
Reflecting IPv6 Flow Label at server nodes is useful in environments that employ multipath routing to load balance the requests. As "IPv6 Flow Label Reflection" standard draft [1] points out - ICMPv6 PTB error messages generated in response to a downstream packets from the server can be routed by a load balancer back to the original server without looking at transport headers, if the server applies the flow label reflection. This enables the Path MTU Discovery past the ECMP router in load-balance or anycast environments where each server node is reachable by only one path. Introduce a sysctl to enable flow label reflection per net namespace for all newly created sockets. Same could be earlier achieved only per socket by setting the IPV6_FL_F_REFLECT flag for the IPV6_FLOWLABEL_MGR socket option. [1] https://tools.ietf.org/html/draft-wang-6man-flow-label-reflection-01 Signed-off-by:
Jakub Sitnicki <jkbs@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bhumika Goyal authored
Make this const as it is only passed as an argument to the function mlx5e_create_netdev and the corresponding argument is of type const. Signed-off-by:
Bhumika Goyal <bhumirks@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Bhumika Goyal authored
Make these const as they are only used in a copy operation. Signed-off-by:
Bhumika Goyal <bhumirks@gmail.com> Reviewed-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Jesper Dangaard Brouer says: ==================== xdp: more work on xdp tracepoints More work on streamlining and performance optimizing the tracepoints for XDP. I've created a simple xdp_monitor application that uses this tracepoint, and prints statistics. Available at github: https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/samples/bpf/xdp_monitor_kern.c https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/samples/bpf/xdp_monitor_user.c The improvement over tracepoint with strcpy: 9810372 - 8428762 = +1381610 pps faster - (1/9810372 - 1/8428762)*10^9 = -16.7 nanosec - 100-(8428762/9810372*100) = strcpy-trace is 14.08% slower - 981037/8428762*100 = removing strcpy made it 11.64% faster V3: Fix merge conflict with commit e4a8e817 ("bpf: misc xdp redirect cleanups") V2: Change trace_xdp_redirect() to align with args of trace_xdp_exception() ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jesper Dangaard Brouer authored
Remove the net_device string name from the xdp_exception tracepoint, like the xdp_redirect tracepoint. Align the TP_STRUCT to have common entries between these two tracepoint. Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jesper Dangaard Brouer authored
There is too much overhead in the current trace_xdp_redirect tracepoint as it does strcpy and strlen on the net_device names. Besides, exposing the ifindex/index is actually the information that is needed in the tracepoint to diagnose issues. When a lookup fails (either ifindex or devmap index) then there is a need for saying which to_index that have issues. V2: Adjust args to be aligned with trace_xdp_exception. Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jesper Dangaard Brouer authored
For XDP_REDIRECT the use of return code -EINVAL is confusing, as it is used in three different cases. (1) When the index or ifindex lookup fails, and in the ixgbe driver (2) when link is down and (3) when XDP have not been enabled. The return code can be picked up by the tracepoint xdp:xdp_redirect for diagnosing why XDP_REDIRECT isn't working. Thus, there is a need different return codes to tell the issues apart. I'm considering using a specific err-code scheme for XDP_REDIRECT instead of using these errno codes. Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jesper Dangaard Brouer authored
If the xdp_do_generic_redirect() call fails, it trigger the trace_xdp_exception tracepoint. It seems better to use the same tracepoint trace_xdp_redirect, as the native xdp_do_redirect{,_map} does. Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jesper Dangaard Brouer authored
Given there is a tracepoint that can track the error code of xdp_do_redirect calls, the WARN_ONCE in bpf_warn_invalid_xdp_redirect doesn't seem relevant any longer. Simply remove the function. Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Jiri Pirko says: ==================== mlxsw: Add IPv4 host dpipe table Arkadi says: This patchset adds IPv4 host dpipe table support. This will provide the ability to observe the hardware offloaded IPv4 neighbors. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arkadi Sharshevsky authored
Add support for controlling neighbor counters via dpipe. Signed-off-by:
Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arkadi Sharshevsky authored
Add support for IPv4 host table dump. Signed-off-by:
Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arkadi Sharshevsky authored
Add support for setting counters on neighbors based on dpipe's host table counter status. This patch also adds the ability for getting the counter value, which will be used by the dpipe host table implementation in the next patches. Signed-off-by:
Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arkadi Sharshevsky authored
This is done as a preparation before introducing support for neighbor counters. The flow counter's type enum is used by many registers, yet, until now it was used only by mgpc and thus it was private. This patch updates the namespace for more generic usage. Signed-off-by:
Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arkadi Sharshevsky authored
Add IPv4 host table initial support. Signed-off-by:
Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arkadi Sharshevsky authored
Change label name for case of erif table init failure. Signed-off-by:
Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arkadi Sharshevsky authored
This is done as a preparation before introducing the ability to dump the host table via dpipe, and to count the table size. The mlxsw's neighbor representative struct stays private to the router module. Signed-off-by:
Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arkadi Sharshevsky authored
The entry clear routine can be shared between the drivers, thus it is moved inside devlink. Signed-off-by:
Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arkadi Sharshevsky authored
Up until now the dpipe table's size was static and known at registration time. The host table does not have constant size and it is resized in dynamic manner. In order to support this behavior the size is changed to be obtained dynamically via an op. This patch also adjust the current dpipe table for the new API. Signed-off-by:
Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arkadi Sharshevsky authored
Fix ERIF's table operations name space. Signed-off-by:
Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arkadi Sharshevsky authored
This will be used by the IPv4 host table which will be introduced in the following patches. This header is global and can be reused by many drivers. Signed-off-by:
Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arkadi Sharshevsky authored
This will be used by the IPv4 host table which will be introduced in the following patches. This header is global and can be reused by many drivers. Signed-off-by:
Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- Aug 24, 2017
-
-
Daniel Borkmann authored
No need to test for it in fast-path, every dev in bpf_dtab_netdev is guaranteed to be non-NULL, otherwise dev_map_update_elem() will fail in the first place. Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
John Fastabend <john.fastabend@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Shubham Bansal authored
As eBPF JIT support for arm32 was added recently with commit 39c13c20 , it seems appropriate to add arm32 as arch with support for eBPF JIT in bpf and sysctl docs as well. Signed-off-by:
Shubham Bansal <illusionist.neo@gmail.com> Acked-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Edward Cree says: ==================== bpf: verifier fixes Fix a couple of bugs introduced in my recent verifier patches. Patch #2 does slightly increase the insn count on bpf_lxc.o, but only by about a hundred insns (i.e. 0.2%). v2: added test for write-marks bug (patch #1); reworded comment on propagate_liveness() for clarity. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Edward Cree authored
The liveness tracking algorithm is quite subtle; add comments to explain it. Signed-off-by:
Edward Cree <ecree@solarflare.com> Acked-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Edward Cree authored
The optimisation it does is broken when the 'new' register value has a variable offset and the 'old' was constant. I broke it with my pointer types unification (see Fixes tag below), before which the 'new' value would have type PTR_TO_MAP_VALUE_ADJ and would thus not compare equal; other changes in that patch mean that its original behaviour (ignore min/max values) cannot be restored. Tests on a sample set of cilium programs show no change in count of processed instructions. Fixes: f1174f77 ("bpf/verifier: rework value tracking") Signed-off-by:
Edward Cree <ecree@solarflare.com> Acked-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Alexei Starovoitov authored
The test makes a read through a map value pointer, then considers pruning a branch where the register holds an adjusted map value pointer. It should not prune, but currently it does. Signed-off-by:
Alexei Starovoitov <ast@fb.com> [ecree@solarflare.com: added test-name and patch description] Signed-off-by:
Edward Cree <ecree@solarflare.com> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Edward Cree authored
The fact that writes occurred in reaching the continuation state does not screen off its reads from us, because we're not really its parent. So detect 'not really the parent' in do_propagate_liveness, and ignore write marks in that case. Fixes: dc503a8a ("bpf/verifier: track liveness for pruning") Signed-off-by:
Edward Cree <ecree@solarflare.com> Acked-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Edward Cree authored
Writes in straight-line code should not prevent reads from propagating along jumps. With current verifier code, the jump from 3 to 5 does not add a read mark on 3:R0 (because 5:R0 has a write mark), meaning that the jump from 1 to 3 gets pruned as safe even though R0 is NOT_INIT. Verifier output: 0: (61) r2 = *(u32 *)(r1 +0) 1: (35) if r2 >= 0x0 goto pc+1 R1=ctx(id=0,off=0,imm=0) R2=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) R10=fp0 2: (b7) r0 = 0 3: (35) if r2 >= 0x0 goto pc+1 R0=inv0 R1=ctx(id=0,off=0,imm=0) R2=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) R10=fp0 4: (b7) r0 = 0 5: (95) exit from 3 to 5: safe from 1 to 3: safe processed 8 insns, stack depth 0 Signed-off-by:
Edward Cree <ecree@solarflare.com> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Colin Ian King authored
iph is being assigned the same value twice; remove the redundant first assignment. (Thanks to Nikolay Aleksandrov for pointing out that the first asssignment should be removed and not the second) Fixes warning: net/ipv4/ip_gre.c:265:2: warning: Value stored to 'iph' is never read Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-