- 09 Nov, 2018 4 commits
-
-
Sowmini Varadhan authored
This patch allows eBPF programs that use sock_ops to send perf based event notifications using bpf_perf_event_output(). Our main use case for this is the following: We would like to monitor some subset of TCP sockets in user-space, (the monitoring application would define 4-tuples it wants to monitor) using TCP_INFO stats to analyze reported problems. The idea is to use those stats to see where the bottlenecks are likely to be ("is it application-limited?" or "is there evidence of BufferBloat in the path?" etc). Today we can do this by periodically polling for tcp_info, but this could be made more efficient if the kernel would asynchronously notify the application via tcp_info when some "interesting" thresholds (e.g., "RTT variance > X", or "total_retrans > Y" etc) are reached. And to make this effective, it is better if we could apply the threshold check *before* constructing the tcp_info netlink notification, so that we don't waste resources constructing notifications that will be discarded by the filter. This work solves the problem by adding perf event based notification support for sock_ops. The eBPF program can thus be designed to apply any desired filters to the bpf_sock_ops and trigger a perf event notification based on the evaluation from the filter. The user space component can use these perf event notifications to either read any state managed by the eBPF program, or issue a TCP_INFO netlink call if desired. Signed-off-by:
Sowmini Varadhan <sowmini.varadhan@oracle.com> Co-developed-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net>
-
Daniel Borkmann authored
Jiong Wang says: ==================== The maximum packet offset accessed by one BPF program is useful information. Because sometimes there could be packet split and it is possible for some reasons (for example performance) we want to reject the BPF program if the maximum packet size would trigger such split. Normally, MTU value is treated as the maximum packet size, but one BPF program does not always access the whole packet, it could only access the head portion of the data. We could let verifier calculate the maximum packet offset ever used and record it inside prog auxiliar information structure as a new field "max_pkt_offset". ==================== Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net>
-
Jiong Wang authored
NFP is refusing to offload programs whenever the MTU is set to a value larger than the max packet bytes that fits in NFP Cluster Target Memory (CTM). However, a eBPF program doesn't always need to access the whole packet data. Verifier has always calculated maximum direct packet access (DPA) offset, and kept it in max_pkt_offset inside prog auxiliar information. This patch relax prog rejection based on max_pkt_offset. Reviewed-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
Jiong Wang <jiong.wang@netronome.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net>
-
Jiong Wang authored
In check_packet_access, update max_pkt_offset after the offset has passed __check_packet_access. It should be safe to use u32 for max_pkt_offset as explained in code comment. Also, when there is tail call, the max_pkt_offset of the called program is unknown, so conservatively set max_pkt_offset to MAX_PACKET_OFF for such case. Reviewed-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
Jiong Wang <jiong.wang@netronome.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net>
-
- 07 Nov, 2018 25 commits
-
-
Shannon Nelson authored
To help when debugging bpf/xdp load issues, have the load_map() error message include the number and name of the map that failed. Signed-off-by:
Shannon Nelson <shannon.nelson@oracle.com> Acked-by:
John Fastabend <john.fastabend@gmail.com> Acked-by:
Song Liu <songliubraving@fb.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net>
-
Quentin Monnet authored
The limit for memory locked in the kernel by a process is usually set to 64 kbytes by default. This can be an issue when creating large BPF maps and/or loading many programs. A workaround is to raise this limit for the current process before trying to create a new BPF map. Changing the hard limit requires the CAP_SYS_RESOURCE and can usually only be done by root user (for non-root users, a call to setrlimit fails (and sets errno) and the program simply goes on with its rlimit unchanged). There is no API to get the current amount of memory locked for a user, therefore we cannot raise the limit only when required. One solution, used by bcc, is to try to create the map, and on getting a EPERM error, raising the limit to infinity before giving another try. Another approach, used in iproute2, is to raise the limit in all cases, before trying to create the map. Here we do the same as in iproute2: the rlimit is raised to infinity before trying to load programs or to create maps with bpftool. Signed-off-by:
Quentin Monnet <quentin.monnet@netronome.com> Reviewed-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by:
Martin KaFai Lau <kafai@fb.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net>
-
Quentin Monnet authored
libbpf is now able to load successfully test_l4lb_noinline.o and samples/bpf/tracex3_kern.o. For the test_l4lb_noinline, uncomment related tests from test_libbpf.c and remove the associated "TODO". For tracex3_kern.o, instead of loading a program from samples/bpf/ that might not have been compiled at this stage, try loading a program from BPF selftests. Since this test case is about loading a program compiled without the "-target bpf" flag, change the Makefile to compile one program accordingly (instead of passing the flag for compiling all programs). Regarding test_xdp_noinline.o: in its current shape the program fails to load because it provides no version section, but the loader needs one. The test was added to make sure that libbpf could load XDP programs even if they do not provide a version number in a dedicated section. But libbpf is already capable of doing that: in our case loading fails because the loader does not know that this is an XDP program (it does not need to, since it does not attach the program). So trying to load test_xdp_noinline.o does not bring much here: just delete this subtest. For the record, the error message obtained with tracex3_kern.o was fixed by commit e3d91b0c ("tools/libbpf: handle issues with bpf ELF objects containing .eh_frames") I have not been abled to reproduce the "libbpf: incorrect bpf_call opcode" error for test_l4lb_noinline.o, even with the version of libbpf present at the time when test_libbpf.sh and test_libbpf_open.c were created. RFC -> v1: - Compile test_xdp without the "-target bpf" flag, and try to load it instead of ../../samples/bpf/tracex3_kern.o. - Delete test_xdp_noinline.o subtest. Cc: Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
Quentin Monnet <quentin.monnet@netronome.com> Acked-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net>
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c: In function 'hclge_log_and_clear_ppp_error': drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c:821:24: warning: variable 'reset_level' set but not used [-Wunused-but-set-variable] enum hnae3_reset_type reset_level = HNAE3_NONE_RESET; It never used since introduction in commit 01865a50 ("net: hns3: Add enable and process hw errors of TM scheduler") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Jakub Kicinski says: ==================== nfp: more set actions and notifier refactor This series brings updates to flower offload code. First Pieter adds support for setting TTL, ToS, Flow Label and Hop Limit fields in IPv4 and IPv6 headers. Remaining 5 patches deal with factoring out netdev notifiers from flower code. We already have two instances, and more is coming, so it's time to move to one central notifier which then feeds individual feature handlers. I start that part by cleaning up the existing notifiers. Next a central notifier is added, and used by flower offloads. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Use driver's common notifier for LAG and tunnel configuration. Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by:
John Hurley <john.hurley@netronome.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Code interested in networking events registers its own notifier handlers. Create one device-wide notifier instance. Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by:
John Hurley <john.hurley@netronome.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
nfp_fl_lag_changels_event() never fails, and therefore we would never return NOTIFY_BAD for NETDEV_CHANGELOWERSTATE. Make this clearer by changing nfp_fl_lag_changels_event()'s return type to void. Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by:
John Hurley <john.hurley@netronome.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Returning an error from a notifier means we want to veto the change. We shouldn't veto NETDEV_UNREGISTER just because we couldn't find the tracking info for given master. I can't seem to find a way to trigger this unless we have some other bug, so it's probably not fix-worthy. While at it move the checking if the netdev really is of interest into the handling functions, like we do for other events. Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by:
John Hurley <john.hurley@netronome.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
For flower tunnel offloads FW has to be informed about MAC addresses of tunnel devices. We use a netdev notifier to keep track of these addresses. Remove unnecessary loop over netdevices after notifier is registered. The intention of the loop was to catch devices which already existed on the system before nfp driver got loaded, but netdev notifier will replay NETDEV_REGISTER events. Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by:
John Hurley <john.hurley@netronome.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Pieter Jansen van Vuuren authored
Add ipv6 set flow label and hop limit action offload. Since pedit sets headers per 4 byte word, we need to ensure that setting either version, priority, payload_len or nexthdr does not get offloaded. Signed-off-by:
Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com> Reviewed-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Pieter Jansen van Vuuren authored
Add ipv4 set ttl and tos action offload. Since pedit sets headers per 4 byte word, we need to ensure that setting either version, ihl, protocol, total length or checksum does not get offloaded. Signed-off-by:
Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com> Reviewed-by:
John Hurley <john.hurley@netronome.com> Reviewed-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Huazhong Tan says: ==================== hns3: provide new interfaces & bugfixes & code optimization This patchset provides some reset interfaces for RAS & RoCE, also some bugfixes and optimization related to reset. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Huazhong Tan authored
It is not necessary to reallocate the descriptor and remap the descriptor memory in reset process, otherwise it may cause memory not freed problem. Also, this patch initializes the cmd queue's spinlocks in hclgevf_alloc_cmd_queue, and take the spinlocks when reinitializing cmd queue' registers. Fixes: fedd0c15 ("net: hns3: Add HNS3 VF IMP(Integrated Management Proc) cmd interface") Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Huazhong Tan authored
When hclge_reset() is called, it may fail for several reasons. For example, an higher-level reset event occurs, memory allocation failure, hardware reset timeout, etc. Therefore, it is necessary to add corresponding error handling for these situations. 1. A high-level reset is required due to a high-level reset failure. 2. For memory allocation failure, a high-level reset is initiated by the timer to recover. The reason for using the timer is to prevent this new high-level reset to interrupt the reset process of other pf/vf; 3. For the case of hardware reset timeout, reschedule the reset task to wait for the hardware to complete the reset. For memory allocation failure and reset timeouts, in order to prevent an infinite number of scheduled reset tasks, the number of error recovery needs to be limited. This patch also add some reset related debug log printing. Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Huazhong Tan authored
While doing resetting, roce should do its uninitailization part before nic's, and do its initialization part after nic's. Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Huazhong Tan authored
When doing PF reset, the driver needs to do some preparatory work before asserting PF reset. Since when hardware is resetting, it is necessary to stop tx/rx queue, clear hardware table, etc, otherwise hardware may run into unrecoverable state if there is still IO running when the hardware is resetting. Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Huazhong Tan authored
Saving reset related information in the hclge_dev/hclgevf_dev structure is more suitable than the hnae3_handle, since hardware related information is kept in these two structure. Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Huazhong Tan authored
When processing a higher level reset, the pending lower level reset does not have to be processed anymore, because the higher level reset is the superset of the lower level reset. Therefore, when processing an higher level reset, the request of lower level reset needs to be cleared. Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Huazhong Tan authored
While hclge is going to reset, it will notify its client with HNAE3_DOWN_CLIENT, so this client should get into a resetting status from this moment, other operations from the stack need to be blocked as well. And when the reset is finished, the client will be notified with HNAE3_UP_CLIENT, so this is the end of the resetting status. This patch uses HNS3_NIC_STATE_RESETTING flag to implement that, and adds hns3_nic_resetting() to indicate which operation is not allowed. Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Huazhong Tan authored
While hardware gets into reset status, the firmware will not respond to driver's command request, which may cause ring not disabled problem during reset process. So this patch uses register instead of command to enable/disable the ring in the enet while doing UP/DOWN operation. Also, HNS3_RING_RX_VM_REG is previously unused, so change it to the correct meaning, and add a wrapper function for readl(). Fixes: 46a3df9f ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Huazhong Tan authored
When doing a function reset, the hardware table should be cleared before the hardware reset. In current code, this clearing is done in hns3_reset_notify_uninit_enet, but it is too late, because the hardware reset is already done, hns3_reset_notify_down_enet is more suitable to do that. Fixes: bb6b94a8 ("net: hns3: Add reset interface implementation in client") Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Huazhong Tan authored
The client needs to know if the hardware is resetting when loading or unloading itself, because client may abort the loading process or wait for the reset process to finish when unloading if hardware is resetting. So this patch provides these interfaces to do it. 1. get_hw_reset_stat, the reset status of hardware. 2. ae_dev_resetting, whether reset task is scheduling. 3. ae_dev_reset_cnt, how many reset has been done. Also, the RoCE client needs some field in the hnae3_roce_private_info to save its state, and process_hw_error interface in the hnae3_client_ops to process hardware errors. Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Huazhong Tan authored
Currently, when reset_event is called because of tx timeout, it will upgrade the reset level (For PF, HNAE3_FUNC_RESET -> HNAE3_CORE_RESET -> HNAE3_GLOBAL_RESET) if the time between the new reset and last reset is within 20 secs, or restore the reset level to HNAE3_FUNC_RESET if the time between the new reset and last reset is over 20 secs. There is requirement that the caller needs to decide the reset level when triggering a reset, for example, RAS recovery. So this patch adds the set_default_reset_request to meet this requirement. Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Huazhong Tan authored
Besides of module_init and module_exit, the process of reset will also uninitialize and initialize the enet client. When reset process fails with enet client uninitialized, the module_exit does not need to uninitialize the enet client, otherwise it may cause double uninitialization problem. So we need the HNS3_NIC_STATE_INITED flag to indicate whether the enet client is initialized. Also HNS3_NIC_STATE_REINITING is previously unused, so change it to HNS3_NIC_STATE_INITED. Fixes: bb6b94a8 ("net: hns3: Add reset interface implementation in client") Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 06 Nov, 2018 11 commits
-
-
David S. Miller authored
Florian Fainelli says: ==================== net: systemport: Unmap queues upon DSA unregister event This patch series fixes the unbinding/binding of the bcm_sf2 switch driver along with bcmsysport which monitors the switch port queues. Because the driver was not processing the DSA_PORT_UNREGISTER event, we would not be unmapping switch port/queues, which could cause incorrect decisions to be made by the HW (e.g: queue always back-pressured). ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
Binding and unbinding the switch driver which creates the DSA slave network devices for which we set-up inspection would lead to undesireable effects since we were not clearing the port/queue mapping to the SYSTEMPORT TX queue. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
The use of a bitmap speeds up the finding of the first available queue to which we could start establishing the mapping for, but we still have to loop over all slave network devices to set them up. Simplify the logic to have a single loop, and use the fact that a correctly configured ring has inspect set to true. This will make things simpler to unwind during device unregistration. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
We are binding to the PHY using the SF2 slave MDIO bus that we create, binding involves reading the PHY's MII_PHYSID1/2 which won't be possible if the PHY is turned off. Temporarily turn it on/off for the bus probing to succeeed. This fixes unbind/bind problems where the port connecting to that PHY would be in error since it could not connect to it. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Florian Fainelli says: ==================== net: dsa: bcm_sf2: Store rules in lists This patch series changes the bcm-sf2 driver to keep a copy of the inserted rules as opposed to using the HW as a storage area for a number of reasons: - this helps us with doing duplicate rule detection in a faster way, it would have required a full rule read before - this helps with Pablo's on-going work to convert ethtool_rx_flow_spec to a more generic flow rule structure by having fewer code paths to convert to the new structure/helpers - we need to cache copies to restore them during drive resumption, because depending on the low power mode the system has entered, the switch may have lost all of its context ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
Some of the system suspend states that we support wipe out entirely the HW contents. If we had a Wake-on-LAN filter programmed prior to going into suspend, but we did not actually wake-up from Wake-on-LAN and instead used a deeper suspend state, make sure we restore the CID number that we need to match against. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
Now that we have migrated the CFP rule handling to a list with a software copy, the delete/get operation just returns what is on the list, no need to read from the hardware which is both slow and more error prone. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
The hardware can lose its context during system suspend, and depending on the switch generation (7445 vs. 7278), while the rules are still there, they will have their valid bit cleared (because that's the fastest way for the HW to reset things). Just make sure we re-apply them coming back from resume. The 7445 switch is an older version of the core that has some quirky RAM technology requiring a delete then re-inser to guarantee the RAM entries are properly latched. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
In preparation for restoring CFP rules during system wide system suspend/resume where the hardware loses its context, split the rule validation from its actual insertion as well as the rule removal from its actual hardware deletion operation. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
We tried hard to use the hardware as a storage area, which made things needlessly complex in that we had to both marshall and unmarshall the ethtool_rx_flow_spec into what the CFP hardware understands but it did not require any driver level allocations, so that was nice. Keep a copy of the ethtool_rx_flow_spec rule we want to insert, and also make sure we don't have a duplicate rule already. This greatly speeds up the deletion time since we only need to clear the slice's valid bit and not perform a full read. This is a preparatory step for being able to restore rules upon system resumption where the hardware loses its context partially or entirely. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
David Ahern says: ==================== net: More extack messages Add more extack messages for several link create errors (e.g., invalid number of queues, unknown link kind) and invalid metrics argument. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-