- 30 Jan, 2021 25 commits
-
-
Eric Dumazet authored
Use cache friendly helpers to better use cpu caches while reading /proc/net/netstat Tested on a platform with 256 threads (AMD Rome) Before: 305 usec spent in netstat_seq_show() After: 130 usec spent in netstat_seq_show() Signed-off-by:
Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20210128162145.1703601-1-eric.dumazet@gmail.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Kuniyuki Iwashima authored
The commit 41b14fb8 ("net: Do not clear the sock TX queue in sk_set_socket()") removes sk_tx_queue_clear() from sk_set_socket() and adds it instead in sk_alloc() and sk_clone_lock() to fix an issue introduced in the commit e022f0b4 ("net: Introduce sk_tx_queue_mapping"). On the other hand, the original commit had already put sk_tx_queue_clear() in sk_prot_alloc(): the callee of sk_alloc() and sk_clone_lock(). Thus sk_tx_queue_clear() is called twice in each path. If we remove sk_tx_queue_clear() in sk_alloc() and sk_clone_lock(), it currently works well because (i) sk_tx_queue_mapping is defined between sk_dontcopy_begin and sk_dontcopy_end, and (ii) sock_copy() called after sk_prot_alloc() in sk_clone_lock() does not overwrite sk_tx_queue_mapping. However, if we move sk_tx_queue_mapping out of the no copy area, it introduces a bug unintentionally. Therefore, this patch adds a compile-time check to take care of the order of sock_copy() and sk_tx_queue_clear() and removes sk_tx_queue_clear() from sk_prot_alloc() so that it does the only allocation and its callers initialize fields. CC: Boris Pismenny <borisp@mellanox.com> Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.co.jp> Acked-by:
Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20210128150217.6060-1-kuniyu@amazon.co.jpSigned-off-by:
-
Jakub Kicinski authored
Huazhong Tan says: ==================== net: hns3: updates for -next This patchset adds dump tm info of nodes, priority and qset in debugfs. Three debugfs files tm_nodes, tm_priority and tm_qset are created in new tm directory, and use cat command to dump their info, for examples: $ cat tm_nodes BASE_ID MAX_NUM PG 0 8 PRI 0 8 QSET 0 8 QUEUE 0 1024 $ cat tm_priority ID MODE DWRR C_IR_B C_IR_U C_IR_S C_BS_B C_BS_S C_FLAG C_RATE(Mbps) P_IR_B P_IR_U P_IR_S P_BS_B P_BS_S P_FLAG P_RATE(Mbps) 0000 dwrr 100 0 0 0 5 20 0 0 150 7 0 5 20 0 0 0001 sp 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0002 sp 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0003 sp 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0004 sp 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0005 sp 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0006 sp 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0007 sp 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 $ cat tm_qset ID MAP_PRI LINK_VLD MODE DWRR 0000 0 1 dwrr 100 0001 0 0 sp 0 0002 0 0 sp 0 0003 0 0 sp 0 0004 0 0 sp 0 0005 0 0 sp 0 0006 0 0 sp 0 change log: V2: add readonly files for dump all nodes, priority and qset info suggested by Jakub Kicinski. previous version: V1: https://patchwork.kernel.org/project/netdevbpf/patch/1610694569-43099-1-git-send-email-tanhuazhong@huawei.com/ ==================== Link: https://lore.kernel.org/r/1611834696-56207-1-git-send-email-tanhuazhong@huawei.comSigned-off-by: -
Guangbin Huang authored
In order to query tm info of nodes, priority and qset for debugging, adds three debugfs files tm_nodes, tm_priority and tm_qset in newly created tm directory. Unlike previous debugfs commands, these three files just support read ops, so they only support to use cat command to dump their info. The new tm file style is acccording to suggestion from Jakub Kicinski's opinion as link https://lkml.org/lkml/2020/9/29/2101. Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Guangbin Huang authored
Add some interfaces to get information of tm priority and qset, then they can be used by debugfs. Signed-off-by:
-
Jakub Kicinski authored
Xin Long says: ==================== net: add support for ip generic checksum offload for gre This patchset it to add ip generic csum processing first in skb_csum_hwoffload_help() in Patch 1/2 and then add csum offload support for GRE header in Patch 2/2. ==================== Link: https://lore.kernel.org/r/cover.1611825446.git.lucien.xin@gmail.comSigned-off-by:
-
Xin Long authored
This patch is to add csum offload support for gre header: On the TX path in gre_build_header(), when CHECKSUM_PARTIAL's set for inner proto, it will calculate the csum for outer proto, and inner csum will be offloaded later. Otherwise, CHECKSUM_PARTIAL and csum_start/offset will be set for outer proto, and the outer csum will be offloaded later. On the GSO path in gre_gso_segment(), when CHECKSUM_PARTIAL is not set for inner proto and the hardware supports csum offload, CHECKSUM_PARTIAL and csum_start/offset will be set for outer proto, and outer csum will be offloaded later. Otherwise, it will do csum for outer proto by calling gso_make_checksum(). Note that SCTP has to do the csum by itself for non GSO path in sctp_packet_pack(), as gre_build_header() can't handle the csum with CHECKSUM_PARTIAL set for SCTP CRC csum offload. v1->v2: - remove the SCTP part, as GRE dev doesn't support SCTP CRC CSUM and it will always do checksum for SCTP in sctp_packet_pack() when it's not a GSO packet. Signed-off-by:Xin Long <lucien.xin@gmail.com> Signed-off-by:
-
Xin Long authored
NETIF_F_IP|IPV6_CSUM feature flag indicates UDP and TCP csum offload while NETIF_F_HW_CSUM feature flag indicates ip generic csum offload for HW, which includes not only for TCP/UDP csum, but also for other protocols' csum like GRE's. However, in skb_csum_hwoffload_help() it only checks features against NETIF_F_CSUM_MASK(NETIF_F_HW|IP|IPV6_CSUM). So if it's a non TCP/UDP packet and the features doesn't support NETIF_F_HW_CSUM, but supports NETIF_F_IP|IPV6_CSUM only, it would still return 0 and leave the HW to do csum. This patch is to support ip generic csum processing by checking NETIF_F_HW_CSUM for all protocols, and check (NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM) only for TCP and UDP. Note that we're using skb->csum_offset to check if it's a TCP/UDP proctol, this might be fragile. However, as Alex said, for now we only have a few L4 protocols that are requesting Tx csum offload, we'd better fix this until a new protocol comes with a same csum offset. v1->v2: - not extend skb->csum_not_inet, but use skb->csum_offset to tell if it's an UDP/TCP csum packet. v2->v3: - add a note in the changelog, as Willem suggested. Suggested-by:Alexander Duyck <alexander.duyck@gmail.com> Signed-off-by:
-
Jakub Kicinski authored
Merge tag 'linux-can-next-for-5.12-20210129' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== linux-can-next-for-5.12-20210129 All patches are by me and target the mcp251xfd driver. The first 4 patches update the information regarding the "85% of (FSYSCLK/2)" errata. The other 4 are misc cleanups, unitfy error messages, add missing postfix to a macro, simplify the return of a function, and make use of dev_err_probe() in the mcp251xfd_probe() function. ==================== Link: https://lore.kernel.org/r/20210129084302.3040284-1-mkl@pengutronix.deSigned-off-by:
-
Loic Poulain authored
Use the new mhi_get_free_desc_count helper to track queue usage instead of relying on the locally maintained rx_queued count. Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Signed-off-by:
-
Loic Poulain authored
The RX queue size can be determined at runtime by retrieving the number of available transfer descriptors. Signed-off-by:
-
https://git.kernel.org/pub/scm/linux/kernel/git/mani/mhiJakub Kicinski authored
Needed by mhi-net patches. Signed-off-by: -
Jan Luebbe authored
This section was missed during the conversion to ReST, so convert it in the same style as the surrounding section titles. Signed-off-by:
Jan Luebbe <jlu@pengutronix.de> Link: https://lore.kernel.org/r/20210128111930.29473-1-jlu@pengutronix.deSigned-off-by:
-
dingsenjie authored
Simplify the code by using module_platform_driver macro for octeon_mgmt. Signed-off-by:
dingsenjie <dingsenjie@yulong.com> Link: https://lore.kernel.org/r/20210128035330.17676-1-dingsenjie@163.comSigned-off-by:
-
Emil Renner Berthing authored
This converts the driver to use the new tasklet API introduced in commit 12cc923f ("tasklet: Introduce new initialization API") Signed-off-by:
Emil Renner Berthing <kernel@esmil.dk> Link: https://lore.kernel.org/r/20210127173256.13954-2-kernel@esmil.dkSigned-off-by:
-
Emil Renner Berthing authored
Previously a temporary tasklet structure was initialized on the stack using DECLARE_TASKLET_OLD() and then copied over and modified. Nothing else in the kernel seems to use this pattern, so let's just call tasklet_init() like everyone else. Signed-off-by:
-
Jakub Kicinski authored
Paul Blakey says: ==================== net/sched: cls_flower: Add support for matching on ct_state reply flag This patchset adds software match support and offload of flower match ct_state reply flag (+/-rpl). The first patch adds the definition for the flag and match to flower. Second patch gives the direction of the connection to the offloading drivers via ct_metadata flow offload action. The last patch does offload of this new ct_state by using the supplied connection's direction. ==================== Link: https://lore.kernel.org/r/1611757967-18236-1-git-send-email-paulb@nvidia.comSigned-off-by:
-
Paul Blakey authored
Add support for matching on ct_state reply flag. Example: $ tc filter add dev ens1f0_0 ingress prio 1 chain 1 proto ip flower \ ct_state +trk+est+rpl \ action mirred egress redirect dev ens1f0_1 $ tc filter add dev ens1f0_1 ingress prio 1 chain 1 proto ip flower \ ct_state +trk+est-rpl \ action mirred egress redirect dev ens1f0_0 Signed-off-by:
Paul Blakey <paulb@nvidia.com> Acked-by:
Saeed Mahameed <saeedm@nvidia.com> Signed-off-by:
-
Paul Blakey authored
Give offloading drivers the direction of the offloaded ct flow, this will be used for matches on direction (ct_state +/-rpl). Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
-
Paul Blakey authored
Add match on the ct_state reply flag. Example: $ tc filter add dev ens1f0_0 ingress prio 1 chain 1 proto ip flower \ ct_state +trk+est+rpl \ action mirred egress redirect dev ens1f0_1 $ tc filter add dev ens1f0_1 ingress prio 1 chain 1 proto ip flower \ ct_state +trk+est-rpl \ action mirred egress redirect dev ens1f0_0 Signed-off-by:
-
Jakub Kicinski authored
Bongsu Jeon says: ==================== Add nci suit and virtual nci device driver 1/2 is the Virtual NCI device driver. 2/2 is the NCI selftest suite ==================== Link: https://lore.kernel.org/r/20210127130829.4026-1-bongsu.jeon@samsung.comSigned-off-by:
-
Bongsu Jeon authored
This is the NCI test suite. It tests the NFC/NCI module using virtual NCI device. Test cases consist of making the virtual NCI device on/off and controlling the device's polling for NCI1.0 and NCI2.0 version. Signed-off-by:
Bongsu Jeon <bongsu.jeon@samsung.com> Signed-off-by:
-
Bongsu Jeon authored
NCI virtual device simulates a NCI device to the user. It can be used to validate the NCI module and applications. This driver supports communication between the virtual NCI device and NCI module. Signed-off-by:
-
Menglong Dong authored
It's better make 'pkt_sk()' inline here, as non-inline function shouldn't occur in headers. Besides, this function is simple enough to be inline. Signed-off-by:
Menglong Dong <dong.menglong@zte.com.cn> Link: https://lore.kernel.org/r/20210127123302.29842-1-dong.menglong@zte.com.cnSigned-off-by:
-
Andrea Parri (Microsoft) authored
Pointers to receive-buffer packets sent by Hyper-V are used within the guest VM. Hyper-V can send packets with erroneous values or modify packet fields after they are processed by the guest. To defend against these scenarios, copy (sections of) the incoming packet after validating their length and offset fields in netvsc_filter_receive(). In this way, the packet can no longer be modified by the host. Reported-by:
Juan Vazquez <juvazq@microsoft.com> Signed-off-by:
Andrea Parri (Microsoft) <parri.andrea@gmail.com> Link: https://lore.kernel.org/r/20210126162907.21056-1-parri.andrea@gmail.comSigned-off-by:
-
- 29 Jan, 2021 15 commits
-
-
Marc Kleine-Budde authored
dev_err_probe() can reduce code size, uniform error handling and record the defer probe reason etc., use it to simplify the code. Link: https://lore.kernel.org/r/20210128104644.2982125-9-mkl@pengutronix.deSigned-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
This patch simplifies the return of the mcp251xfd_chip_clock_enable() function by direct returning the error. Link: https://lore.kernel.org/r/20210128104644.2982125-8-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
As MCP251XFD_OBJ_FLAGS_DLC is a mask, add the missing _MASK postfix, that all other masks in the driver have. Link: https://lore.kernel.org/r/20210128104644.2982125-7-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
This patch unifies the error messages: - have a "." and the end of each message - write controller with a small "c", if not the first word of an error message. Link: https://lore.kernel.org/r/20210128104644.2982125-6-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
This patch adds an imx6 as known good to the errata table. Link: https://lore.kernel.org/r/20210128104644.2982125-5-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
The published errata specify the maximum allowed SPI frequency to be max 85% of (FSYSCLK/2). So there's no need to track known bad clock settings in the driver. As the setup of known good values is a bit tricky, keep them. Link: https://lore.kernel.org/r/20210128104644.2982125-4-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
This patch sorts the errata table alphabetically and fixes the indention. Link: https://lore.kernel.org/r/20210128104644.2982125-3-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
This patch fixes the reference to the errata for both the mcp2517fd and the mcp2518fd. Fixes: f5b84ded ("can: mcp25xxfd: mcp25xxfd_probe(): add SPI clk limit related errata information") Link: https://lore.kernel.org/r/20210128104644.2982125-2-mkl@pengutronix.deSigned-off-by:
-
Bjorn Helgaas authored
Fix misspellings of "physical". Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/20210127181359.3008316-1-helgaas@kernel.orgSigned-off-by:
-
dingsenjie authored
allocted -> allocated Signed-off-by:
-
Jakub Kicinski authored
Petr Machata says: ==================== nexthop: Preparations for resilient next-hop groups At this moment, there is only one type of next-hop group: an mpath group. Mpath groups implement the hash-threshold algorithm, described in RFC 2992[1]. To select a next hop, hash-threshold algorithm first assigns a range of hashes to each next hop in the group, and then selects the next hop by comparing the SKB hash with the individual ranges. When a next hop is removed from the group, the ranges are recomputed, which leads to reassignment of parts of hash space from one next hop to another. RFC 2992 illustrates it thus: +-------+-------+-------+-------+-------+ | 1 | 2 | 3 | 4 | 5 | +-------+-+-----+---+---+-----+-+-------+ | 1 | 2 | 4 | 5 | +---------+---------+---------+---------+ Before and after deletion of next hop 3 under the hash-threshold algorithm. Note how next hop 2 gave up part of the hash space in favor of next hop 1, and 4 in favor of 5. While there will usually be some overlap between the previous and the new distribution, some traffic flows change the next hop that they resolve to. If a multipath group is used for load-balancing between multiple servers, this hash space reassignment causes an issue that packets from a single flow suddenly end up arriving at a server that does not expect them, which may lead to TCP reset. If a multipath group is used for load-balancing among available paths to the same server, the issue is that different latencies and reordering along the way causes the packets to arrive in wrong order. Resilient hashing is a technique to address the above problem. Resilient next-hop group has another layer of indirection between the group itself and its constituent next hops: a hash table. The selection algorithm uses a straightforward modulo operation to choose a hash bucket, and then reads the next hop that this bucket contains, and forwards traffic there. This indirection brings an important feature. In the hash-threshold algorithm, the range of hashes associated with a next hop must be continuous. With a hash table, mapping between the hash table buckets and the individual next hops is arbitrary. Therefore when a next hop is deleted the buckets that held it are simply reassigned to other next hops: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1|1|1|2|2|2|2|3|3|3|3|4|4|4|4|5|5|5|5| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v v v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1|1|1|2|2|2|2|1|2|4|5|4|4|4|4|5|5|5|5| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Before and after deletion of next hop 3 under the resilient hashing algorithm. When weights of next hops in a group are altered, it may be possible to choose a subset of buckets that are currently not used for forwarding traffic, and use those to satisfy the new next-hop distribution demands, keeping the "busy" buckets intact. This way, established flows are ideally kept being forwarded to the same endpoints through the same paths as before the next-hop group change. This patchset prepares the next-hop code for eventual introduction of resilient hashing groups. - Patches #1-#4 carry otherwise disjoint changes that just remove certain assumptions in the next-hop code. - Patches #5-#6 extend the in-kernel next-hop notifiers to support more next-hop group types. - Patches #7-#12 refactor RTNL message handlers. Resilient next-hop groups will introduce a new logical object, a hash table bucket. It turns out that handling bucket-related messages is similar to how next-hop messages are handled. These patches extract the commonalities into reusable components. The plan is to contribute approximately the following patchsets: 1) Nexthop policy refactoring (already pushed) 2) Preparations for resilient next hop groups (this patchset) 3) Implementation of resilient next hop group 4) Netdevsim offload plus a suite of selftests 5) Preparations for mlxsw offload of resilient next-hop groups 6) mlxsw offload including selftests Interested parties can look at the current state of the code at [2] and [3]. [1] https://tools.ietf.org/html/rfc2992 [2] https://github.com/idosch/linux/commits/submit/res_integ_v1 [3] https://github.com/idosch/iproute2/commits/submit/res_v1 ==================== Link: https://lore.kernel.org/r/cover.1611836479.git.petrm@nvidia.comSigned-off-by: -
Petr Machata authored
Validation of messages for get / del of a next hop is the same as will be validation of messages for get of a resilient next hop group bucket. The difference is that policy for resilient next hop group buckets is a superset of that used for next-hop get. It is therefore possible to reuse the code that validates the nhmsg fields, extracts the next-hop ID, and validates that. To that end, extract from nh_valid_get_del_req() a helper __nh_valid_get_del_req() that does just that. Make the nlh argument const so that the function can be called from the dump context, which only has a const nlh. Propagate the constness to nh_valid_get_del_req(). Signed-off-by:
Petr Machata <petrm@nvidia.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Signed-off-by:
-
Petr Machata authored
In order to allow different handling for next-hop tree dumper and for bucket dumper, parameterize the next-hop tree walker with a callback. Add rtm_dump_nexthop_cb() with just the bits relevant for next-hop tree dumping. Signed-off-by:
-
Petr Machata authored
Extract from rtm_dump_nexthop() a helper to walk the next hop tree. A separate function for this will be reusable from the bucket dumper. Signed-off-by:
-
Petr Machata authored
The dump operations need to keep state from one invocation to another. A scratch area is dedicated for this purpose in the passed-in argument, cb, namely via two aliased arrays, struct netlink_callback.args and .ctx. Dumping of buckets will end up having to iterate over next hops as well, and it would be nice to be able to reuse the iteration logic with the NH dumper. The fact that the logic currently relies on fixed index to the .args array, and the indices would have to be coordinated between the two dumpers, makes this somewhat awkward. To make the access patters clearer, introduce a helper struct with a NH index, and instead of using the .args array directly, use it through this structure. Signed-off-by:
-
