- 16 Jan, 2020 11 commits
-
-
Pablo Neira Ayuso authored
Consolidate code to configure the flow_cls_offload structure into one helper function. Signed-off-by:Pablo Neira Ayuso <pablo@netfilter.org>
-
Florian Westphal authored
no need, just use a simple boolean to indicate we want to reap all entries. Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
Pablo Neira Ayuso authored
If nf_flow_offload_add() fails to add the flow to hardware, then the NF_FLOW_HW_REFRESH flag bit is set and the flow remains in the flowtable software path. If flowtable hardware offload is enabled, this patch enqueues a new request to offload this flow to hardware. Signed-off-by: -
Pablo Neira Ayuso authored
This function checks for the NF_FLOWTABLE_HW_OFFLOAD flag, meaning that the flowtable hardware offload is enabled. Signed-off-by: -
Pablo Neira Ayuso authored
Originally, all flow flag bits were set on only from the workqueue. With the introduction of the flow teardown state and hardware offload this is no longer true. Let's be safe and use atomic bitwise operation to operation with flow flags. Fixes: 59c466dd ("netfilter: nf_flow_table: add a new flow state for tearing down offloading") Signed-off-by:
-
Pablo Neira Ayuso authored
The dying bit removes the conntrack entry if the netdev that owns this flow is going down. Instead, use the teardown mechanism to push back the flow to conntrack to let the classic software path decide what to do with it. Signed-off-by: -
Pablo Neira Ayuso authored
Add helper function to allocate and initialize flow offload work and use it to consolidate existing code. Signed-off-by: -
Pablo Neira Ayuso authored
Set on FLOW_DISSECTOR_KEY_META meta key using flow tuple ingress interface. Fixes: c29f74e0 ("netfilter: nf_flow_table: hardware offload support") Signed-off-by:
-
Pablo Neira Ayuso authored
Do not fetch statistics if flow has expired since it might not in hardware anymore. After this update, remove the FLOW_OFFLOAD_HW_DYING check from nf_flow_offload_stats() since this flag is never set on. Fixes: c29f74e0 ("netfilter: nf_flow_table: hardware offload support") Signed-off-by:
wenxu <wenxu@ucloud.cn>
-
Jeremy Sowden authored
The comment documenting how bitwise expressions work includes a table which summarizes the mask and xor arguments combined to express the supported boolean operations. However, the row for OR: mask xor 0 x is incorrect. dreg = (sreg & 0) ^ x is not equivalent to: dreg = sreg | x What the code actually does is: dreg = (sreg & ~x) ^ x Update the documentation to match. Signed-off-by:
Jeremy Sowden <jeremy@azazel.net> Signed-off-by:
-
YueHaibing authored
Remove duplicated include. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 15 Jan, 2020 29 commits
-
-
Jacob Keller authored
Review of the recently added documentation file for the qed driver noticed a couple of typos. Fix them now. Noticed-by:
Michal Kalderon <mkalderon@marvell.com> Fixes: 0f261c3c ("devlink: add a driver-specific file for the qed driver") Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
-
Ulrich Weber authored
use sk_bound_dev_if for route lookup as already done in most of the other ip_route_output_ports() calls. Since most PPPoA providers use 10.0.0.138 as default gateway IP this will allow connections to multiple PPTP providers with the same IP address over different interfaces. Signed-off-by:
Ulrich Weber <ulrich.weber@gmail.com> Signed-off-by:
-
git://git.open-mesh.org/linux-mergeDavid S. Miller authored
Simon Wunderlich says: ==================== This feature/cleanup patchset includes the following patches: - bump version strings, by Simon Wunderlich - fix typo and kerneldocs, by Sven Eckelmann - use WiFi txbitrate for B.A.T.M.A.N. V as fallback, by René Treffer - silence some endian sparse warnings by adding annotations, by Sven Eckelmann - Update copyright years to 2020, by Sven Eckelmann - Disable deprecated sysfs configuration by default, by Sven Eckelmann ==================== Signed-off-by: -
David S. Miller authored
Nikolay Aleksandrov says: ==================== net: bridge: add vlan notifications and rtm support This patch-set is a prerequisite for adding per-vlan options support because we need to be able to send vlan-only notifications and do larger vlan netlink dumps. Per-vlan options are needed as we move the control more to vlans and would like to add per-vlan state (needed for per-vlan STP and EVPN), per-vlan multicast options and control, and I'm sure there would be many more per-vlan options coming. Now we create/delete/dump vlans with the device AF_SPEC attribute which is fine since we support vlan ranges or use a compact bridge_vlan_info structure, but that cannot really be extended to support per-vlan options well. The biggest issue is dumping them - we tried using the af_spec with a new vlan option attribute but that led to insufficient message size quickly, also another minor problem with that is we have to dump all vlans always when notifying which, with options present, can be huge if they have different options set, so we decided to add new rtm message types specifically for vlans and register handlers for them and a new bridge vlan notification nl group for vlan-only notifications. The new RTM NEW/DEL/GETVLAN types introduced match the current af spec bridge functionality and in fact use the same helpers. The new nl format is: [BRIDGE_VLANDB_ENTRY] [BRIDGE_VLANDB_ENTRY_INFO] - bridge_vlan_info (either 1 vlan or range start) [BRIDGE_VLANDB_ENTRY_RANGE] - range end This allows to encapsulate a range in a single attribute and also to create vlans and immediately set options on all of them with a single attribute. The GETVLAN dump can span multiple messages and dump all the necessary information. The vlan-only notifications are sent on NEW/DELVLAN events or when vlan options change (currently only flags), we try hard to compress the vlans into ranges in the notifications as well. When the per-vlan options are added we'll add helpers to check for option equality between neighbor vlans and will keep compressing them when possible. Note patch 02 is not really required, it's just a nice addition to have human-readable error messages from the different vlan checks. iproute2 changes and selftests will be sent with the next set which adds the first per-vlan option - per-vlan state similar to the port state. v2: changed patch 03 and patch 04 to use nlmsg_parse() in order to strictly validate the msg and make sure there are no remaining bytes ==================== Signed-off-by: -
Nikolay Aleksandrov authored
Now that we can notify, send a notification on add/del or change of flags. Notifications are also compressed when possible to reduce their number and relieve user-space of extra processing, due to that we have to manually notify after each add/del in order to avoid double notifications. We try hard to notify only about the vlans which actually changed, thus a single command can result in multiple notifications about disjoint ranges if there were vlans which didn't change inside. Signed-off-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
-
Nikolay Aleksandrov authored
Add a new rtnetlink group for bridge vlan notifications - RTNLGRP_BRVLAN and add support for sending vlan notifications (both single and ranges). No functional changes intended, the notification support will be used by later patches. Signed-off-by:
-
Nikolay Aleksandrov authored
Add a new vlandb nl attribute - BRIDGE_VLANDB_ENTRY_RANGE which causes RTM_NEWVLAN/DELVAN to act on a range. Dumps now automatically compress similar vlans into ranges. This will be also used when per-vlan options are introduced and vlans' options match, they will be put into a single range which is encapsulated in one netlink attribute. We need to run similar checks as br_process_vlan_info() does because these ranges will be used for options setting and they'll be able to skip br_process_vlan_info(). Signed-off-by:
-
Nikolay Aleksandrov authored
Adding RTM_DELVLAN support similar to RTM_NEWVLAN is simple, just need to map DELVLAN to DELLINK and register the handler. Signed-off-by:
-
Nikolay Aleksandrov authored
Add initial RTM_NEWVLAN support which can only create vlans, operating similar to the current br_afspec(). We will use it later to also change per-vlan options. Old-style (flag-based) vlan ranges are not allowed when using RTM messages, we will introduce vlan ranges later via a new nested attribute which would allow us to have all the information about a range encapsulated into a single nl attribute. Signed-off-by:
-
Nikolay Aleksandrov authored
This patch adds vlan rtm definitions: - NEWVLAN: to be used for creating vlans, setting options and notifications - DELVLAN: to be used for deleting vlans - GETVLAN: used for dumping vlan information Dumping vlans which can span multiple messages is added now with basic information (vid and flags). We use nlmsg_parse() to validate the header length in order to be able to extend the message with filtering attributes later. Signed-off-by:
-
Nikolay Aleksandrov authored
Add extack messages on vlan processing errors. We need to move the flags missing check after the "last" check since we may have "last" set but lack a range end flag in the next entry. Signed-off-by:
-
Nikolay Aleksandrov authored
Add helpers to check if a vlan id or range are valid. The range helper must be called when range start or end are detected. Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== net: Add route offload indication This patch set adds offload indication to IPv4 and IPv6 routes. So far offload indication was only available for the nexthop via 'RTNH_F_OFFLOAD', which is problematic as a nexthop is usually shared between multiple routes. Based on feedback from Roopa and David on the RFC [1], the indication is split to 'offload' and 'trap'. This is done because not all the routes present in hardware actually offload traffic from the kernel. For example, host routes merely trap packets to the kernel. The two flags are dumped to user space via the 'rtm_flags' field in the ancillary header of the rtnetlink message. In addition, the patch set uses the new flags in order to test the FIB offload API by adding a dummy FIB offload implementation to netdevsim. The new tests are added to a shared library and can be therefore shared between different drivers. Patches #1-#3 add offload indication to IPv4 routes. Patches #4 adds offload indication to IPv6 routes. Patches #5-#6 add support for the offload indication in mlxsw. Patch #7 adds dummy FIB offload implementation in netdevsim. Patches #8-#10 add selftests. v2 (feedback from David Ahern): * Patch #2: Name last argument of fib_dump_info() * Patch #2: Move 'struct fib_rt_info' to include/net/ip_fib.h so that it could later be passed to fib_alias_hw_flags_set() * Patch #3: Make use of 'struct fib_rt_info' in fib_alias_hw_flags_set() * Patch #6: Convert to new fib_alias_hw_flags_set() interface * Patch #7: Convert to new fib_alias_hw_flags_set() interface [1] https://patchwork.ozlabs.org/cover/1170530/ ==================== Signed-off-by:
-
Ido Schimmel authored
The test reuses the common FIB offload tests in order to make sure that mlxsw correctly implements FIB offload. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Acked-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Ido Schimmel authored
Test various aspects of the FIB offload API on top of the netdevsim implementation. Both good and bad flows are tested. Signed-off-by:
-
Ido Schimmel authored
Implement a set of common helpers and tests for FIB offload that can be used by multiple drivers to check their FIB offload implementations. Signed-off-by:
-
Ido Schimmel authored
Implement dummy IPv4 and IPv6 FIB "offload" in the driver by storing currently "programmed" routes in a hash table. Each route in the hash table is marked with "trap" indication. The indication is cleared when the route is replaced or when the netdevsim instance is deleted. This will later allow us to test the route offload API on top of netdevsim. v2: * Convert to new fib_alias_hw_flags_set() interface Signed-off-by:
-
Ido Schimmel authored
Previous patches added support for two hardware flags for IPv4 and IPv6 routes: 'RTM_F_OFFLOAD' and 'RTM_F_TRAP'. Both indicate the presence of the route in hardware. The first indicates that traffic is actually offloaded from the kernel, whereas the second indicates that packets hitting such routes are trapped to the kernel for processing (e.g., host routes). Use these two flags in mlxsw. The flags are modified in two places. Firstly, whenever a route is updated in the device's table. This includes the addition, deletion or update of a route. For example, when a host route is promoted to perform NVE decapsulation, its action in the device is updated, the 'RTM_F_OFFLOAD' flag set and the 'RTM_F_TRAP' flag cleared. Secondly, when a route is replaced and overwritten by another route, its flags are cleared. v2: * Convert to new fib_alias_hw_flags_set() interface Signed-off-by:
-
Ido Schimmel authored
The driver currently uses the 'RTNH_F_OFFLOAD' flag for both routes and nexthops, which is cumbersome and unnecessary now that we have separate flag for the route itself. Separate the offload indication for nexthops from routes and call it whenever the offload state within the nexthop group changes. Note that IPv6 (unlike IPv4) does not share the same nexthop group between different routes, whereas mlxsw does. Therefore, whenever the offload indication within an IPv6 nexthop group changes, all the linked routes need to be updated. Signed-off-by:
-
Ido Schimmel authored
In a similar fashion to previous patch, add "offload" and "trap" indication to IPv6 routes. This is done by using two unused bits in 'struct fib6_info' to hold these indications. Capable drivers are expected to set these when processing the various in-kernel route notifications. Signed-off-by:
David Ahern <dsahern@gmail.com> Acked-by:
Roopa Prabhu <roopa@cumulusnetworks.com> Signed-off-by:
-
Ido Schimmel authored
When performing L3 offload, routes and nexthops are usually programmed into two different tables in the underlying device. Therefore, the fact that a nexthop resides in hardware does not necessarily mean that all the associated routes also reside in hardware and vice-versa. While the kernel can signal to user space the presence of a nexthop in hardware (via 'RTNH_F_OFFLOAD'), it does not have a corresponding flag for routes. In addition, the fact that a route resides in hardware does not necessarily mean that the traffic is offloaded. For example, unreachable routes (i.e., 'RTN_UNREACHABLE') are programmed to trap packets to the CPU so that the kernel will be able to generate the appropriate ICMP error packet. This patch adds an "offload" and "trap" indications to IPv4 routes, so that users will have better visibility into the offload process. 'struct fib_alias' is extended with two new fields that indicate if the route resides in hardware or not and if it is offloading traffic from the kernel or trapping packets to it. Note that the new fields are added in the 6 bytes hole and therefore the struct still fits in a single cache line [1]. Capable drivers are expected to invoke fib_alias_hw_flags_set() with the route's key in order to set the flags. The indications are dumped to user space via a new flags (i.e., 'RTM_F_OFFLOAD' and 'RTM_F_TRAP') in the 'rtm_flags' field in the ancillary header. v2: * Make use of 'struct fib_rt_info' in fib_alias_hw_flags_set() [1] struct fib_alias { struct hlist_node fa_list; /* 0 16 */ struct fib_info * fa_info; /* 16 8 */ u8 fa_tos; /* 24 1 */ u8 fa_type; /* 25 1 */ u8 fa_state; /* 26 1 */ u8 fa_slen; /* 27 1 */ u32 tb_id; /* 28 4 */ s16 fa_default; /* 32 2 */ u8 offload:1; /* 34: 0 1 */ u8 trap:1; /* 34: 1 1 */ u8 unused:6; /* 34: 2 1 */ /* XXX 5 bytes hole, try to pack */ struct callback_head rcu __attribute__((__aligned__(8))); /* 40 16 */ /* size: 56, cachelines: 1, members: 12 */ /* sum members: 50, holes: 1, sum holes: 5 */ /* sum bitfield members: 8 bits (1 bytes) */ /* forced alignments: 1, forced holes: 1, sum forced holes: 5 */ /* last cacheline: 56 bytes */ } __attribute__((__aligned__(8))); Signed-off-by: -
Ido Schimmel authored
fib_dump_info() is used to prepare RTM_{NEW,DEL}ROUTE netlink messages using the passed arguments. Currently, the function takes 11 arguments, 6 of which are attributes of the route being dumped (e.g., prefix, TOS). The next patch will need the function to also dump to user space an indication if the route is present in hardware or not. Instead of passing yet another argument, change the function to take a struct containing the different route attributes. v2: * Name last argument of fib_dump_info() * Move 'struct fib_rt_info' to include/net/ip_fib.h so that it could later be passed to fib_alias_hw_flags_set() Signed-off-by: -
Ido Schimmel authored
Subsequent patches will add an offload / trap indication to routes which will signal if the route is present in hardware or not. After programming the route to the hardware, drivers will have to ask the IPv4 code to set the flags by passing the route's key. In the case of route replace, the new route is notified before it is actually inserted into the FIB alias list. This can prevent simple drivers (e.g., netdevsim) that program the route to the hardware in the same context it is notified in from being able to set the flag. Solve this by first inserting the new route to the list and rollback the operation in case the route was vetoed. Signed-off-by:
-
Lorenzo Bianconi authored
Socionext driver can run on dma coherent and non-coherent devices. Get rid of huge dma_sync_single_for_device in netsec_alloc_rx_data since now the driver can let page_pool API to managed needed DMA sync Reviewed-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Acked-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
-
David S. Miller authored
Bjorn Andersson says: ==================== QRTR flow control improvements In order to prevent overconsumption of resources on the remote side QRTR implements a flow control mechanism. Move the handling of the incoming confirm_rx to the receiving process to ensure incoming flow is controlled. Then implement outgoing flow control, using the recommended algorithm of counting outstanding non-confirmed messages and blocking when hitting a limit. The last three patches refactors the node assignment and port lookup, in order to remove the worker in the receive path. ==================== Signed-off-by: -
Bjorn Andersson authored
Rather than enqueuing messages and scheduling a worker to deliver them to the individual sockets we can now, thanks to the previous work, move this directly into the endpoint callback. This saves us a context switch per incoming message and removes the possibility of an opportunistic suspend to happen between the message is coming from the endpoint until it ends up in the socket's receive buffer. Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Bjorn Andersson authored
The important part of qrtr_port_lookup() wrt synchronization is that the function returns a reference counted struct qrtr_sock, or fail. As such we need only to ensure that an decrement of the object's refcount happens inbetween the finding of the object in the idr and qrtr_port_lookup()'s own increment of the object. By using RCU and putting a synchronization point after we remove the mapping from the idr, but before it can be released we achieve this - with the benefit of not having to hold the mutex in qrtr_port_lookup(). Signed-off-by:
-
Bjorn Andersson authored
Move operations on the qrtr_nodes radix tree under a separate spinlock and make the qrtr_nodes tree GFP_ATOMIC, to allow operation from atomic context in a subsequent patch. Signed-off-by:
-
Bjorn Andersson authored
In order to prevent overconsumption of resources on the remote side QRTR implements a flow control mechanism. The mechanism works by the sender keeping track of the number of outstanding unconfirmed messages that has been transmitted to a particular node/port pair. Upon count reaching a low watermark (L) the confirm_rx bit is set in the outgoing message and when the count reaching a high watermark (H) transmission will be blocked upon the reception of a resume_tx message from the remote, that resets the counter to 0. This guarantees that there will be at most 2H - L messages in flight. Values chosen for L and H are 5 and 10 respectively. Signed-off-by:
-
