- 08 Nov, 2018 22 commits
-
-
Justin Chen authored
Add support for BCM7255 EPHY. Signed-off-by:
Justin Chen <justinpopo6@gmail.com> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Paolo Abeni says: ==================== udp: implement GRO support This series implements GRO support for UDP sockets, as the RX counterpart of commit bec1f6f6 ("udp: generate gso with UDP_SEGMENT"). The core functionality is implemented by the second patch, introducing a new sockopt to enable UDP_GRO, while patch 3 implements support for passing the segment size to the user space via a new cmsg. UDP GRO performs a socket lookup for each ingress packets and aggregate datagram directed to UDP GRO enabled sockets with constant l4 tuple. UDP GRO packets can land on non GRO-enabled sockets, e.g. due to iptables NAT rules, and that could potentially confuse existing applications. The solution adopted here is to de-segment the GRO packet before enqueuing as needed. Since we must cope with packet reinsertion after de-segmentation, the relevant code is factored-out in ipv4 and ipv6 specific helpers and exposed to UDP usage. While the current code can probably be improved, this safeguard ,implemented in the patches 4-7, allows future enachements to enable UDP GSO offload on more virtual devices eventually even on forwarded packets. The last 4 for patches implement some performance and functional self-tests, re-using the existing udpgso infrastructure. The problematic scenario described above is explicitly tested. This revision of the series try to address the feedback provided by Willem and Subash on previous iteration. ==================== Acked-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Paolo Abeni authored
Extends the existing udp programs to allow checking for proper GRO aggregation/GSO size, and run the tests via a shell script, using a veth pair with XDP program attached to trigger the GRO code path. rfc v3 -> v1: - use ip route to attach the xdp helper to the veth rfc v2 -> rfc v3: - add missing test program options documentation - fix sporatic test failures (receiver faster than sender) Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Paolo Abeni authored
Run on top of veth pair, using a dummy XDP program to enable the GRO. rfc v3 -> v1: - use ip route to attach the xdp helper to the veth Signed-off-by:
-
Paolo Abeni authored
This trivial XDP program does nothing, but will be used by the next patch to test the GRO path in a net namespace, leveraging the veth XDP implementation. It's added here, despite its 'net' usage, to avoid the duplication of the llc-related makefile boilerplate. rfc v3 -> v1: - move the helper implementation into the bpf directory, don't touch udpgso_bench_rx rfc v2 -> rfc v3: - move 'x' option handling here Signed-off-by:
-
Paolo Abeni authored
And fix a couple of buglets (port option processing, clean termination on SIGINT). This is preparatory work for GRO tests. rfc v2 -> rfc v3: - use ETH_MAX_MTU Signed-off-by:
-
Paolo Abeni authored
In some scenarios, the GRO engine can assemble an UDP GRO packet that ultimately lands on a non GRO-enabled socket. This patch tries to address the issue explicitly checking for the UDP socket features before enqueuing the packet, and eventually segmenting the unexpected GRO packet, as needed. We must also cope with re-insertion requests: after segmentation the UDP code calls the helper introduced by the previous patches, as needed. Segmentation is performed by a common helper, which takes care of updating socket and protocol stats is case of failure. rfc v3 -> v1 - fix compile issues with rxrpc - when gso_segment returns NULL, treat is as an error - added 'ipv4' argument to udp_rcv_segment() rfc v2 -> rfc v3 - moved udp_rcv_segment() into net/udp.h, account errors to socket and ns, always return NULL or segs list Signed-off-by:
-
Paolo Abeni authored
So that we can re-use it at the UDP level in the next patch rfc v3 -> v1: - add the helper declaration into the ipv6 header Signed-off-by:
-
Paolo Abeni authored
So that we can re-use it at the UDP level in a later patch rfc v3 -> v1 - add the helper declaration into the ip header Signed-off-by:
-
Paolo Abeni authored
When UDP GRO is enabled, the UDP_GRO cmsg will carry the ingress datagram size. User-space can use such info to compute the original packets layout. Signed-off-by:
-
Paolo Abeni authored
This is the RX counterpart of commit bec1f6f6 ("udp: generate gso with UDP_SEGMENT"). When UDP_GRO is enabled, such socket is also eligible for GRO in the rx path: UDP segments directed to such socket are assembled into a larger GSO_UDP_L4 packet. The core UDP GRO support is enabled with setsockopt(UDP_GRO). Initial benchmark numbers: Before: udp rx: 1079 MB/s 769065 calls/s After: udp rx: 1466 MB/s 24877 calls/s This change introduces a side effect in respect to UDP tunnels: after a UDP tunnel creation, now the kernel performs a lookup per ingress UDP packet, while before such lookup happened only if the ingress packet carried a valid internal header csum. rfc v2 -> rfc v3: - fixed typos in macro name and comments - really enforce UDP_GRO_CNT_MAX, instead of UDP_GRO_CNT_MAX + 1 - acquire socket lock in UDP_GRO setsockopt rfc v1 -> rfc v2: - use a new option to enable UDP GRO - use static keys to protect the UDP GRO socket lookup Signed-off-by:
-
Paolo Abeni authored
The *encap_needed static keys are enabled by UDP tunnels and several UDP encapsulations type, but they are never turned off. This can cause unneeded overall performance degradation for systems where such features are used transiently. This patch introduces complete book-keeping for such keys, decreasing the usage at socket destruction time, if needed, and avoiding that the same socket could increase the key usage multiple times. rfc v3 -> v1: - add socket lock around udp_tunnel_encap_enable() rfc v2 -> rfc v3: - use udp_tunnel_encap_enable() in setsockopt() Signed-off-by:
-
David S. Miller authored
Mike Manning says: ==================== vrf: allow simultaneous service instances in default and other VRFs Services currently have to be VRF-aware if they are using an unbound socket. One cannot have multiple service instances running in the default and other VRFs for services that are not VRF-aware and listen on an unbound socket. This is because there is no easy way of isolating packets received in the default VRF from those arriving in other VRFs. This series provides this isolation for stream sockets subject to the existing kernel parameter net.ipv4.tcp_l3mdev_accept not being set, given that this is documented as allowing a single service instance to work across all VRF domains. Similarly, net.ipv4.udp_l3mdev_accept is checked for datagram sockets, and net.ipv4.raw_l3mdev_accept is introduced for raw sockets. The functionality applies to UDP & TCP services as well as those using raw sockets, and is for IPv4 and IPv6. Example of running ssh instances in default and blue VRF: $ /usr/sbin/sshd -D $ ip vrf exec vrf-blue /usr/sbin/sshd $ ss -ta | egrep 'State|ssh' State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 0.0.0.0%vrf-blue:ssh 0.0.0.0:* LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:* ESTAB 0 0 192.168.122.220:ssh 192.168.122.1:50282 LISTEN 0 128 [::]%vrf-blue:ssh [::]:* LISTEN 0 128 [::]:ssh [::]:* ESTAB 0 0 [3000::2]%vrf-blue:ssh [3000::9]:45896 ESTAB 0 0 [2000::2]:ssh [2000::9]:46398 v1: - Address Paolo Abeni's comments (patch 4/5) - Fix build when CONFIG_NET_L3_MASTER_DEV not defined (patch 1/5) v2: - Address David Aherns' comments (patches 4/5 and 5/5) - Remove patches 3/5 and 5/5 from series for individual submissions - Include a sysctl for raw sockets as recommended by David Ahern - Expand series into 10 patches and provide improved descriptions v3: - Update description for patch 1/10 and remove patch 6/10 v4: - Set default to enabled for raw socket sysctl as recommended by David Ahern v5: - Address review comments from David Ahern in patches 2-5 ==================== Signed-off-by: -
Dewi Morgan authored
For bound udp sockets in a vrf, also check the sdif to get the index for ingress devices enslaved to an l3mdev. Signed-off-by:
Dewi Morgan <morgand@vyatta.att-mail.com> Signed-off-by:
Mike Manning <mmanning@vyatta.att-mail.com> Reviewed-by:
David Ahern <dsahern@gmail.com> Tested-by:
-
Mike Manning authored
If the skb for multicast packets marked as enslaved to a VRF are received, then the secondary device index should be used to obtain the real device. And verify the multicast address against the enslaved rather than the l3mdev device. Signed-off-by:
-
Mike Manning authored
If link-local packets are marked as enslaved to a VRF, then to allow ping to the link-local from a vrf, the error handling for IPV6_PKTINFO needs to be relaxed to also allow the pkt ipi6_ifindex to be that of a slave device to the vrf. Note that the real device also needs to be retrieved in icmp6_iif() to set the ipv6 flow oif to this for icmp echo reply handling. The recent commit 24b711ed ("net/ipv6: Fix linklocal to global address with VRF") takes care of this, so the sdif does not need checking here. This fix makes ping to link-local consistent with that to global addresses, in that this can now be done from within the same VRF that the address is in. Signed-off-by:
-
Mike Manning authored
The skb for packets that are multicast or to a link-local address are not marked as being enslaved to a VRF, if they are received on a socket bound to the VRF. This is needed for ND and it is preferable for the kernel not to have to deal with the additional use-cases if ll or mcast packets are handled as enslaved. However, this does not allow service instances listening on unbound and bound to VRF sockets to distinguish the VRF used, if packets are sent as multicast or to a link-local address. The fix is for the VRF driver to also mark these skb as being enslaved to the VRF. Signed-off-by:
-
Duncan Eastoe authored
When there exist a pair of raw sockets one unbound and one bound to a VRF but equal in all other respects, when a packet is received in the VRF context, __raw_v4_lookup() matches on both sockets. This results in the packet being delivered over both sockets, instead of only the raw socket bound to the VRF. The bound device checks in __raw_v4_lookup() are replaced with a call to raw_sk_bound_dev_eq() which correctly handles whether the packet should be delivered over the unbound socket in such cases. In __raw_v6_lookup() the match on the device binding of the socket is similarly updated to use raw_sk_bound_dev_eq() which matches the handling in __raw_v4_lookup(). Importantly raw_sk_bound_dev_eq() takes the raw_l3mdev_accept sysctl into account. Signed-off-by:
Duncan Eastoe <deastoe@vyatta.att-mail.com> Signed-off-by:
-
Mike Manning authored
Add a sysctl raw_l3mdev_accept to control raw socket lookup in a manner similar to use of tcp_l3mdev_accept for stream and of udp_l3mdev_accept for datagram sockets. Have this default to enabled for reasons of backwards compatibility. This is so as to specify the output device with cmsg and IP_PKTINFO, but using a socket not bound to the corresponding VRF. This allows e.g. older ping implementations to be run with specifying the device but without executing it in the VRF. If the option is disabled, packets received in a VRF context are only handled by a raw socket bound to the VRF, and correspondingly packets in the default VRF are only handled by a socket not bound to any VRF. Signed-off-by:
-
Mike Manning authored
Ensure an unbound datagram skt is chosen when not in a VRF. The check for a device match in compute_score() for UDP must be performed when there is no device match. For this, a failure is returned when there is no device match. This ensures that bound sockets are never selected, even if there is no unbound socket. Allow IPv6 packets to be sent over a datagram skt bound to a VRF. These packets are currently blocked, as flowi6_oif was set to that of the master vrf device, and the ipi6_ifindex is that of the slave device. Allow these packets to be sent by checking the device with ipi6_ifindex has the same L3 scope as that of the bound device of the skt, which is the master vrf device. Note that this check always succeeds if the skt is unbound. Even though the right datagram skt is now selected by compute_score(), a different skt is being returned that is bound to the wrong vrf. The difference between these and stream sockets is the handling of the skt option for SO_REUSEPORT. While the handling when adding a skt for reuse correctly checks that the bound device of the skt is a match, the skts in the hashslot are already incorrect. So for the same hash, a skt for the wrong vrf may be selected for the required port. The root cause is that the skt is immediately placed into a slot when it is created, but when the skt is then bound using SO_BINDTODEVICE, it remains in the same slot. The solution is to move the skt to the correct slot by forcing a rehash. Signed-off-by:
-
Mike Manning authored
The commit a04a480d ("net: Require exact match for TCP socket lookups if dif is l3mdev") only ensures that the correct socket is selected for packets in a VRF. However, there is no guarantee that the unbound socket will be selected for packets when not in a VRF. By checking for a device match in compute_score() also for the case when there is no bound device and attaching a score to this, the unbound socket is selected. And if a failure is returned when there is no device match, this ensures that bound sockets are never selected, even if there is no unbound socket. Signed-off-by:
-
Robert Shearman authored
Change the inet socket lookup to avoid packets arriving on a device enslaved to an l3mdev from matching unbound sockets by removing the wildcard for non sk_bound_dev_if and instead relying on check against the secondary device index, which will be 0 when the input device is not enslaved to an l3mdev and so match against an unbound socket and not match when the input device is enslaved. Change the socket binding to take the l3mdev into account to allow an unbound socket to not conflict sockets bound to an l3mdev given the datapath isolation now guaranteed. Signed-off-by:
Robert Shearman <rshearma@vyatta.att-mail.com> Signed-off-by:
-
- 07 Nov, 2018 18 commits
-
-
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 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: -
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:
-
Jakub Kicinski authored
Code interested in networking events registers its own notifier handlers. Create one device-wide notifier instance. Signed-off-by:
-
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 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 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:
-
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:
-
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:
-
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: -
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:
-
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 authored
While doing resetting, roce should do its uninitailization part before nic's, and do its initialization part after nic's. Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
-
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 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 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 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 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:
-
