- 14 Oct, 2020 6 commits
-
-
Tonghao Zhang authored
Allow user configuring RXCSUM separately with ethtool -K, reusing the existing virtnet_set_guest_offloads helper that configures RXCSUM for XDP. This is conditional on VIRTIO_NET_F_CTRL_GUEST_OFFLOADS. If Rx checksum is disabled, LRO should also be disabled. Signed-off-by:
Tonghao Zhang <xiangxia.m.yue@gmail.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Acked-by:
Jason Wang <jasowang@redhat.com> Acked-by:
Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/20201012015820.62042-1-xiangxia.m.yue@gmail.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Or Cohen authored
Commit 109f6e39 ("af_unix: Allow SO_PEERCRED to work across namespaces.") introduced the old_pid variable in unix_listen, but it's never used. Remove the declaration and the call to put_pid. Signed-off-by:
Or Cohen <orcohen@paloaltonetworks.com> Link: https://lore.kernel.org/r/20201011153527.18628-1-orcohen@paloaltonetworks.comSigned-off-by:
-
Julia Lawall authored
Replace commas with semicolons. Commas introduce unnecessary variability in the code structure and are hard to see. What is done is essentially described by the following Coccinelle semantic patch (http://coccinelle.lip6.fr/): // <smpl> @@ expression e1,e2; @@ e1 -, +; e2 ... when any // </smpl> Signed-off-by:
Julia Lawall <Julia.Lawall@inria.fr> Link: https://lore.kernel.org/r/1602412498-32025-6-git-send-email-Julia.Lawall@inria.frSigned-off-by:
-
Julia Lawall authored
Replace commas with semicolons. Commas introduce unnecessary variability in the code structure and are hard to see. What is done is essentially described by the following Coccinelle semantic patch (http://coccinelle.lip6.fr/): // <smpl> @@ expression e1,e2; @@ e1 -, +; e2 ... when any // </smpl> Signed-off-by:
Paul Moore <paul@paul-moore.com> Link: https://lore.kernel.org/r/1602412498-32025-5-git-send-email-Julia.Lawall@inria.frSigned-off-by:
-
Julia Lawall authored
Replace commas with semicolons. Commas introduce unnecessary variability in the code structure and are hard to see. What is done is essentially described by the following Coccinelle semantic patch (http://coccinelle.lip6.fr/): // <smpl> @@ expression e1,e2; @@ e1 -, +; e2 ... when any // </smpl> Signed-off-by:
-
Vladimir Oltean authored
A helper for checking whether a net_device belongs to mscc_ocelot already existed and did not need to be rewritten. Use it. Fixes: 319e4dd1 ("net: mscc: ocelot: introduce conversion helpers between port and netdev") Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20201011092041.3535101-1-vladimir.oltean@nxp.comSigned-off-by:
-
- 13 Oct, 2020 4 commits
-
-
Jakub Kicinski authored
Willy Tarreau says: ==================== macb: support the 2-deep Tx queue on at91 while running some tests on my Breadbee board, I noticed poor network Tx performance. I had a look at the driver (macb, at91ether variant) and noticed that at91ether_start_xmit() immediately stops the queue after sending a frame and waits for the interrupt to restart the queue, causing a dead time after each packet is sent. The AT91RM9200 datasheet states that the controller supports two frames, one being sent and the other one being queued, so I performed minimal changes to support this. The transmit performance on my board has increased by 50% on medium-sized packets (HTTP traffic), and with large packets I can now reach line rate. Since this driver is shared by various platforms, I tried my best to isolate and limit the changes as much as possible and I think it's pretty reasonable as-is. I've run extensive tests and couldn't meet any unexpected situation (no stall, overflow nor lockup). There are 3 patches in this series. The first one adds the missing interrupt flag for RM9200 (TBRE, indicating the tx buffer is willing to take a new packet). The second one replaces the single skb with a 2-array and uses only index 0. It does no other change, this is just to prepare the code for the third one. The third one implements the queue. Packets are added at the tail of the queue, the queue is stopped at 2 packets and the interrupt releases 0, 1 or 2 depending on what the transmit status register reports. ==================== Signed-off-by: -
Willy Tarreau authored
The at91rm9200 variant used by a few chips including the MSC313 supports two Tx descriptors (one frame being serialized and another one queued). However the driver only implemented a single one, which adds a dead time after each transfer to receive and process the interrupt and wake the queue up, preventing from reaching line rate. This patch implements a very basic 2-deep queue to address this limitation. The tests run on a Breadbee board equipped with an MSC313E show that at 1 GHz, HTTP traffic on medium-sized objects (45kB) was limited to exactly 50 Mbps before this patch, and jumped to 76 Mbps with this patch. And tests on a single TCP stream with an MTU of 576 jump from 10kpps to 15kpps. With 1500 byte packets it's now possible to reach line rate versus 75 Mbps before. Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Claudiu Beznea <claudiu.beznea@microchip.com> Cc: Daniel Palmer <daniel@0x0f.com> Signed-off-by:
Willy Tarreau <w@1wt.eu> Link: https://lore.kernel.org/r/20201011090944.10607-4-w@1wt.euSigned-off-by:
-
Willy Tarreau authored
The RM9200 supports one frame being sent while another one is waiting in queue. This avoids the dead time that follows the emission of a frame and which prevents one from reaching line speed. Right now the driver supports only a single skb, so we'll first replace the rm9200-specific skb info with an array of two macb_tx_skb (already used by other drivers). This patch only moves the skb_length to txq[0].size and skb_physaddr to skb[0].mapping but doesn't perform any other change. It already uses [desc] in order to minimize future changes. Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Claudiu Beznea <claudiu.beznea@microchip.com> Cc: Daniel Palmer <daniel@0x0f.com> Signed-off-by:
-
Willy Tarreau authored
Transmit Buffer Register Empty replaces TXERR on RM9200 and signals the sender may try to send again becase the last queued frame is no longer in queue (being transmitted or already transmitted). Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Claudiu Beznea <claudiu.beznea@microchip.com> Cc: Daniel Palmer <daniel@0x0f.com> Signed-off-by:
-
- 12 Oct, 2020 29 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextJakub Kicinski authored
Alexei Starovoitov says: ==================== pull-request: bpf-next 2020-10-12 The main changes are: 1) The BPF verifier improvements to track register allocation pattern, from Alexei and Yonghong. 2) libbpf relocation support for different size load/store, from Andrii. 3) bpf_redirect_peer() helper and support for inner map array with different max_entries, from Daniel. 4) BPF support for per-cpu variables, form Hao. 5) sockmap improvements, from John. ==================== Signed-off-by: -
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-nextJakub Kicinski authored
Pablo Neira Ayuso says: ==================== Netfilter/IPVS updates for net-next The following patchset contains Netfilter/IPVS updates for net-next: 1) Inspect the reply packets coming from DR/TUN and refresh connection state and timeout, from longguang yue and Julian Anastasov. 2) Series to add support for the inet ingress chain type in nf_tables. ==================== Signed-off-by: -
Jakub Kicinski authored
Michael Chan says: ==================== bnxt_en: Updates for net-next. This series contains these main changes: 1. Change of default message level to enable more logging. 2. Some cleanups related to processing async events from firmware. 3. Allow online ethtool selftest on multi-function PFs. 4. Return stored firmware version information to devlink. v2: Patch 3: Change bnxt_reset_task() to silent mode. Patch 8 & 9: Ensure we copy NULL terminated fw strings to devlink. Patch 8 & 9: Return directly after the last bnxt_dl_info_put() call. Patch 9: If FW call to get stored dev info fails, return success to devlink without the stored versions. ==================== Signed-off-by: -
Vasundhara Volam authored
This patch adds FW versions stored in the flash to devlink info_get callback. Return the correct fw.psid running version using the newly added bp->nvm_cfg_ver. v2: Ensure stored pkg_name string is NULL terminated when copied to devlink. Return directly from the last call to bnxt_dl_info_put(). If the FW call to get stored version fails for any reason, return success immediately to devlink without the stored versions. Reviewed-by:
Andy Gospodarek <gospo@broadcom.com> Signed-off-by:
Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/1602493854-29283-10-git-send-email-michael.chan@broadcom.comSigned-off-by:
-
Vasundhara Volam authored
Add a new function bnxt_dl_info_put() to simplify the code, as there are more stored firmware version fields to be added in the next patch. Also, rename fw_ver variable name to ncsi_ver for better naming while copying to devlink info_get cb. v2: Ensure active_pkg_name string is NULL terminated when copied to devlink. Return directly from the last call to bnxt_dl_info_put(). Reviewed-by:
Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by:
-
Vasundhara Volam authored
Add a new bnxt_hwrm_nvm_get_dev_info() to query firmware version information via NVM_GET_DEV_INFO firmware command. Use it to get the running version of the NVM configuration information. This new function will also be used in subsequent patches to get the stored firmware versions. Reviewed-by:
-
Michael Chan authored
If the VF virtual link is set to always enabled, the speed may be unknown when the physical link is down. The driver currently logs the link speed as 4294967295 Mbps which is SPEED_UNKNOWN. Modify the link up log message as "speed unknown" which makes more sense. Reviewed-by:
Edwin Peer <edwin.peer@broadcom.com> Signed-off-by:
-
Michael Chan authored
Log these values that contain useful firmware state information. Reviewed-by:
-
Michael Chan authored
event_data1 and event_data2 are used when processing most events. Store these in local variables at the beginning of the function to simplify many of the case statements. Reviewed-by:
-
Michael Chan authored
Currently, bp->msg_enable has default value of 0. It is more useful to have the commonly used NETIF_MSG_DRV and NETIF_MSG_HW enabled by default. v2: Change the fall back bnxt_reset_task() inside bnxt_rx_ring_reset() to silent mode. With older fw, we would take the fall back path and it would be very noisy. Reviewed-by:
-
Vasundhara Volam authored
Online self tests are not disruptive and can be run in NPAR mode and in multi-host NIC as well. Reviewed-by:
-
Vasundhara Volam authored
If NVRAM resources are locked, NVM writes are not permitted. In such scenarios, firmware returns HWRM_ERR_CODE_RESOURCE_LOCKED error to firmware commands. Reviewed-by:
-
Jakub Kicinski authored
Merge tag 'linux-can-next-for-5.10-20201012' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== linux-can-next-for-5.10-20201012 Both patches are by Oliver Hartkopp, the first one addresses Jakub's review comments of the ISOTP protocol, the other one removes version strings from various CAN protocols. ==================== Signed-off-by:
-
Ondrej Zary authored
Use netdev_err for better device identification in syslog. Signed-off-by:
Ondrej Zary <linux@zary.sk> Signed-off-by:
-
Ondrej Zary authored
When the router is rebooted without a power cycle, the USB device remains connected but its configuration is reset. This results in a non-working ethernet connection with messages like this in syslog: usb 2-2: RX packet too long: 65535 B Re-enable ethernet mode when receiving a packet with invalid size of 0xffff. Signed-off-by:
-
Oliver Hartkopp authored
As pointed out by Jakub Kicinski here: http://lore.kernel.org/r/20201009175751.5c54097f@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com this patch removes the obsolete version information of the different CAN protocols and the AF_CAN core module. Signed-off-by:
Oliver Hartkopp <socketcan@hartkopp.net> Link: https://lore.kernel.org/r/20201012074354.25839-2-socketcan@hartkopp.netSigned-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Oliver Hartkopp authored
As pointed out by Jakub Kicinski here: http://lore.kernel.org/r/20201009175751.5c54097f@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com this patch addresses the remarked issues: - remove empty line in comment - remove default=y for CAN_ISOTP in Kconfig - make use of pr_notice_once() - use GFP_ATOMIC instead of gfp_any() in soft hrtimer context The version strings in the CAN subsystem are removed by a separate patch. Signed-off-by:
-
Alexei Starovoitov authored
John Fastabend says: ==================== This allows a sockmap sk_skb verdict programs to run without a parser. For some use cases, such as verdict program that support streaming data or a l3/l4 proxy that does not use data in packet, loading the nop parser 'return skb->len' is an extra unnecessary complexity. With this series we simply call the verdict program directly from data_ready instead of bouncing through the strparser logic. Patches 1,2 do the lifting on the sockmap side then patches 3,4 add the selftests. This applies on top of the series here, sockmap/sk_skb program memory acct fixes https://patchwork.ozlabs.org/project/netdev/list/?series=206975 it will apply without the above series cleanly, but will have an incorrect memory accounting causing a failure in ./test_sockmap. I could have left it so the series passed without above series, but it seemed odd to have it out there and then require yet another patch to fix it up here. Thanks. --- ==================== Signed-off-by:
Alexei Starovoitov <ast@kernel.org>
-
John Fastabend authored
Here we add three new tests for sockmap to test having a verdict program without setting the parser program. The first test covers the most simply case, sender proxy_recv proxy_send recv | | | | verdict -----+ | | | | | +----------------+ +------------+ We load the verdict program on the proxy_recv socket without a parser program. It then does a redirect into the send path of the proxy_send socket using sendpage_locked(). Next we test the drop case to ensure if we kfree_skb as a result of the verdict program everything behaves as expected. Next we test the same configuration above, but with ktls and a redirect into socket ingress queue. Shown here tls tls sender proxy_recv proxy_send recv | | | | verdict ------------------+ | | redirect_ingress +----------------+ Also to set up ping/pong test Signed-off-by:John Fastabend <john.fastabend@gmail.com> Signed-off-by:
-
John Fastabend authored
Add option to allow running without a parser program in place. To test with ping/pong program use, # test_sockmap -t ping --txmsg_omit_skb_parser this will send packets between two socket bouncing through a proxy socket that does not use a parser program. (ping) (pong) sender proxy_recv proxy_send recv | | | | verdict -----+ | | | | | +----------------+ +------------+ Signed-off-by: -
John Fastabend authored
Currently, we often run with a nop parser namely one that just does this, 'return skb->len'. This happens when either our verdict program can handle streaming data or it is only looking at socket data such as IP addresses and other metadata associated with the flow. The second case is common for a L3/L4 proxy for instance. So lets allow loading programs without the parser then we can skip the stream parser logic and avoid having to add a BPF program that is effectively a nop. Signed-off-by:
-
John Fastabend authored
We are about to allow skb_verdict to run without skb_parser programs as a first step change code to check each program type specifically. This should be a mechanical change without any impact to actual result. Signed-off-by:
-
Alexei Starovoitov authored
John Fastabend says: ==================== Users of sockmap and skmsg trying to build proxys and other tools have pointed out to me the error handling can be problematic. If the proxy is under-provisioned and/or the BPF admin does not have the ability to update/modify memory provisions on the sockets its possible data may be dropped. For some things we have retries so everything works out OK, but for most things this is likely not great. And things go bad. The original design dropped memory accounting on the receive socket as early as possible. We did this early in sk_skb handling and then charged it to the redirect socket immediately after running the BPF program. But, this design caused a fundamental problem. Namely, what should we do if we redirect to a socket that has already reached its socket memory limits. For proxy use cases the network admin can tune memory limits. But, in general we punted on this problem and told folks to simply make your memory limits high enough to handle your workload. This is not a really good answer. When deploying into environments where we expect this to be transparent its no longer the case because we need to tune params. In fact its really only viable in cases where we have fine grained control over the application. For example a proxy redirecting from an ingress socket to an egress socket. The result is I get bug reports because its surprising for one, but more importantly also breaks some use cases. So lets fix it. This series cleans up the different cases so that in many common modes, such as passing packet up to receive socket, we can simply use the underlying assumption that the TCP stack already has done memory accounting. Next instead of trying to do memory accounting against the socket we plan to redirect into we keep memory accounting on the receive socket until the skb can be put on the redirect socket. This means if we do an egress redirect to a socket and sock_writable() returns EAGAIN we can requeue the skb on the workqueue and try again. The same scenario plays out for ingress. If the skb can not be put on the receive queue of the redirect socket than we simply requeue and retry. In both cases memory is still accounted for against the receiving socket. This also handles head of line blocking. With the above scheme the skb is on a queue associated with the socket it will be sent/recv'd on, but the memory accounting is against the received socket. This means the receive socket can advance to the next skb and avoid head of line blocking. At least until its receive memory on the socket runs out. This will put some maximum size on the amount of data any socket can enqueue giving us bounds on the skb lists so they can't grow indefinitely. Overall I think this is a win. Tested with test_sockmap. These are fixes, but I tagged it for bpf-next considering we are at -rc8. v1->v2: Fix uninitialized/unused variables (kernel test robot) v2->v3: fix typo in patch2 err=0 needs to be <0 so use err=-EIO --- ==================== Signed-off-by: -
John Fastabend authored
Move skb->sk assignment out of sk_psock_bpf_run() and into individual callers. Then we can use proper skb_set_owner_r() call to assign a sk to a skb. This improves things by also charging the truesize against the sockets sk_rmem_alloc counter. With this done we get some accounting in place to ensure the memory associated with skbs on the workqueue are still being accounted for somewhere. Finally, by using skb_set_owner_r the destructor is setup so we can just let the normal skb_kfree logic recover the memory. Combined with previous patch dropping skb_orphan() we now can recover from memory pressure and maintain accounting. Note, we will charge the skbs against their originating socket even if being redirected into another socket. Once the skb completes the redirect op the kfree_skb will give the memory back. This is important because if we charged the socket we are redirecting to (like it was done before this series) the sock_writeable() test could fail because of the skb trying to be sent is already charged against the socket. Also TLS case is special. Here we wait until we have decided not to simply PASS the packet up the stack. In the case where we PASS the packet up the stack we already have an skb which is accounted for on the TLS socket context. For the parser case we continue to just set/clear skb->sk this is because the skb being used here may be combined with other skbs or turned into multiple skbs depending on the parser logic. For example the parser could request a payload length greater than skb->len so that the strparser needs to collect multiple skbs. At any rate the final result will be handled in the strparser recv callback. Fixes: 604326b4 ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by:
-
John Fastabend authored
Calling skb_orphan() is unnecessary in the strp rcv handler because the skb is from a skb_clone() in __strp_recv. So it never has a destructor or a sk assigned. Plus its confusing to read because it might hint to the reader that the skb could have an sk assigned which is not true. Even if we did have an sk assigned it would be cleaner to simply wait for the upcoming kfree_skb(). Additionally, move the comment about strparser clone up so its closer to the logic it is describing and add to it so that it is more complete. Fixes: 604326b4 ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by:
-
John Fastabend authored
In the sk_skb redirect case we didn't handle the case where we overrun the sk_rmem_alloc entry on ingress redirect or sk_wmem_alloc on egress. Because we didn't have anything implemented we simply dropped the skb. This meant data could be dropped if socket memory accounting was in place. This fixes the above dropped data case by moving the memory checks later in the code where we actually do the send or recv. This pushes those checks into the workqueue and allows us to return an EAGAIN error which in turn allows us to try again later from the workqueue. Fixes: 51199405 ("bpf: skb_verdict, support SK_PASS on RX BPF path") Signed-off-by:
-
John Fastabend authored
The skb_set_owner_w is unnecessary here. The sendpage call will create a fresh skb and set the owner correctly from workqueue. Its also not entirely harmless because it consumes cycles, but also impacts resource accounting by increasing sk_wmem_alloc. This is charging the socket we are going to send to for the skb, but we will put it on the workqueue for some time before this happens so we are artifically inflating sk_wmem_alloc for this period. Further, we don't know how many skbs will be used to send the packet or how it will be broken up when sent over the new socket so charging it with one big sum is also not correct when the workqueue may break it up if facing memory pressure. Seeing we don't know how/when this is going to be sent drop the early accounting. A later patch will do proper accounting charged on receive socket for the case where skbs get enqueued on the workqueue. Fixes: 604326b4 ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by:
-
John Fastabend authored
When we receive an skb and the ingress skb verdict program returns SK_PASS we currently set the ingress flag and put it on the workqueue so it can be turned into a sk_msg and put on the sk_msg ingress queue. Then finally telling userspace with data_ready hook. Here we observe that if the workqueue is empty then we can try to convert into a sk_msg type and call data_ready directly without bouncing through a workqueue. Its a common pattern to have a recv verdict program for visibility that always returns SK_PASS. In this case unless there is an ENOMEM error or we overrun the socket we can avoid the workqueue completely only using it when we fall back to error cases caused by memory pressure. By doing this we eliminate another case where data may be dropped if errors occur on memory limits in workqueue. Fixes: 51199405 ("bpf: skb_verdict, support SK_PASS on RX BPF path") Signed-off-by:
-
John Fastabend authored
For sk_skb case where skb_verdict program returns SK_PASS to continue to pass packet up the stack, the memory limits were already checked before enqueuing in skb_queue_tail from TCP side. So, lets remove the extra checks here. The theory is if the TCP stack believes we have memory to receive the packet then lets trust the stack and not double check the limits. In fact the accounting here can cause a drop if sk_rmem_alloc has increased after the stack accepted this packet, but before the duplicate check here. And worse if this happens because TCP stack already believes the data has been received there is no retransmit. Fixes: 51199405 ("bpf: skb_verdict, support SK_PASS on RX BPF path") Signed-off-by:
-
- 11 Oct, 2020 1 commit
-
-
Pablo Neira Ayuso authored
Make two unfront calls to pskb_may_pull() to linearize the network and transport header. Signed-off-by:Pablo Neira Ayuso <pablo@netfilter.org>
-
