- 31 Mar, 2021 38 commits
-
-
Anirudh Venkataramanan authored
Check for bail out condition before calling ice_aq_sff_eeprom Signed-off-by:
Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by:
Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com>
-
Bruce Allan authored
Commit a012dca9 ("ice: add ethtool -m support for reading i2c eeprom modules") unnecessarily added the ICE_AQ_FLAG_BUF flag to the descriptor when sending the indirect Read/Write SFF EEPROM AQ command. The flag is already added later in the code flow for all indirect AQ commands, i.e. commands that provide an additional data buffer. Signed-off-by:
Bruce Allan <bruce.w.allan@intel.com> Tested-by:
-
Paul Greenwalt authored
Change link misconfiguration message since the configuration could be intended by the user. Signed-off-by:
Paul Greenwalt <paul.greenwalt@intel.com> Tested-by:
-
Paul M Stillwell Jr authored
There is an issue when the Tx or Rx ring size increases using 'ethtool -L ...' where the new rings don't get the correct ITR values because when we rebuild the VSI we don't know that some of the rings may be new. Fix this by looking at the original number of rings and determining if the rings in ice_vsi_rebuild_set_coalesce() were not present in the original rings received in ice_vsi_rebuild_get_coalesce(). Also change the code to return an error if we can't allocate memory for the coalesce data in ice_vsi_rebuild(). Signed-off-by:
Paul M Stillwell Jr <paul.m.stillwell.jr@intel.com> Tested-by:
-
Dan Nowlin authored
There are two package versions in the package binary. Today, these two version numbers are the same. However, in the future that may change. Update code to use the package info from the ice segment metadata section, which is the package information that is actually downloaded to the firmware during the download package process. Signed-off-by:
Dan Nowlin <dan.nowlin@intel.com> Tested-by:
-
Anirudh Venkataramanan authored
Once a netdev is registered, the corresponding network interface can be immediately used by userspace utilities (like say NetworkManager). This can be problematic if the driver technically isn't fully up yet. Move netdev registration to the end of probe, as by this time the driver data structures and device will be initialized as expected. However, delaying netdev registration causes a failure in the aRFS flow where netdev->reg_state == NETREG_REGISTERED condition is checked. It's not clear why this check was added to begin with, so remove it. Local testing didn't indicate any issues with this change. The state bit check in ice_open was put in as a stop-gap measure to prevent a premature interface up operation. This is no longer needed, so remove it. Signed-off-by:
-
Benita Bose authored
Enable and configure XPS. The driver code implemented sets up the Transmit Packet Steering Map, which in turn will be used by the kernel in queue selection during Tx. Signed-off-by:
Benita Bose <benita.bose@intel.com> Tested-by:
-
Eric Lin authored
Signed-off-by:
Eric Lin <dslin1010@gmail.com> Reported-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
When cleared, the 'force' parameter in nexthop bucket replacement notifications indicates that a driver should try to perform an atomic replacement. Meaning, only update the contents of the bucket if it is inactive. Since mlxsw only queries buckets' activity once every second, there is no point in trying an atomic replacement if the idle timer interval is smaller than 1 second. Currently, mlxsw ignores the original value of 'force' and will always try an atomic replacement if the idle timer is not smaller than 1 second. Fix this by taking the original value of 'force' into account and never promoting a non-atomic replacement to an atomic one. Fixes: 617a77f0 ("mlxsw: spectrum_router: Add nexthop bucket replacement support") Reported-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
-
David S. Miller authored
Mat Martineau says: ==================== MPTCP: Allow initial subflow to be disconnected An MPTCP connection is aggregated from multiple TCP subflows, and can involve multiple IP addresses on either peer. The addresses used in the initial subflow connection are assigned address id 0 on each side of the link. More addresses can be added and shared with the peer using address IDs of 1 or larger. MPTCP in Linux shares non-zero address IDs across all MPTCP connections in a net namespace, which allows userspace to manage subflow connections across a number of sockets. However, this makes the address with id 0 a special case, since the IP address associated with id 0 is potentially different for each socket. This patch set allows the initial subflow to be disconnected when userspace specifies an address to remove using both id 0 and an IP address, or when the peer sends an RM_ADDR for id 0. Patches 1 and 3 implement the change for requests from the peer and userspace, respectively. Patch 2 consolidates some code for disconnecting subflows. Patches 4-6 update the self tests to cover removal of subflows using address id 0. ==================== Signed-off-by: -
Geliang Tang authored
This patch added the testcases for removing the id 0 subflow and the id 0 address. In do_transfer, use the removing addresses number '9' for deleting the id 0 address. Reviewed-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
Geliang Tang <geliangtang@gmail.com> Signed-off-by:
-
Geliang Tang authored
For the id 0 address, different MPTCP connections could be using different IP addresses for id 0. This patch added an extra argument IP address for del_addr when using id 0. Reviewed-by:
-
Matthieu Baerts authored
IDs are supposed to be between 0 and 255. In pm_nl_ctl, for both the 'add' and 'get' instruction, the ID is casted in a u_int8_t. So if we give 256, we will delete ID 0. Obviously, the goal is not to delete this ID by giving 256. We could modify pm_nl_ctl and stop if the ID is negative or higher than 255 but probably better not to increase the number of lines for such things in this tool which is only used in selftests. Instead, we use it within the limits. This modification also means that we will no longer add a new ID for the 2nd entry. That's why we removed an expected entry from the dump and introduced with commit dc8eb10e ("selftests: mptcp: add testcases for setting the address ID"). So now we delete ID 9 like before and we add entries for IDs 10 to 255 that are deleted just after. Note that this could be seen as a fix but it was not really an issue so far: we were simply playing with ID 0/1 once again. With the following commit ("selftests: mptcp: add addr argument for del_addr"), it will be different because ID 0 is going to required an address. We don't want errors when trying to delete ID 0 without the address argument. Acked-and-tested-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
-
Geliang Tang authored
This patch added a new function mptcp_nl_remove_id_zero_address to remove the id 0 address. In this function, traverse all the existing msk sockets to find the msk matched the input IP address. Then fill the removing list with id 0, and pass it to mptcp_pm_remove_addr and mptcp_pm_remove_subflow. Suggested-by:
Paolo Abeni <pabeni@redhat.com> Suggested-by:
-
Geliang Tang authored
There are some duplicate code in mptcp_pm_nl_rm_addr_received and mptcp_pm_nl_rm_subflow_received. This patch unifies them into a new function named mptcp_pm_nl_rm_addr_or_subflow. In it, use the input parameter rm_type to identify it's now removing an address or a subflow. Suggested-by:
-
Geliang Tang authored
There's only one subflow involving the non-zero id address, but there may be multi subflows involving the id 0 address. Here's an example: local_id=0, remote_id=0 local_id=1, remote_id=0 local_id=0, remote_id=1 If the removing address id is 0, all the subflows involving the id 0 address need to be removed. In mptcp_pm_nl_rm_addr_received/mptcp_pm_nl_rm_subflow_received, the "break" prevents the iteration to the next subflow, so this patch dropped them. Reviewed-by:
-
Eric Dumazet authored
sysctl_icmp_echo_enable_probe is an u8. ipv4_net_table entry should use .maxlen = sizeof(u8). .proc_handler = proc_dou8vec_minmax, Fixes: f1b8fa9f ("net: add sysctl for enabling RFC 8335 PROBE messages") Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Andreas Roeseler <andreas.a.roeseler@gmail.com> Signed-off-by:
-
David S. Miller authored
Shannon Nelson says: ==================== ionic: code cleanup for heartbeat, dma error counts, sizeof, stats These patches are a few more bits of code cleanup found in testing and review: count all our dma error instances, make better use of sizeof, fix a race in our device heartbeat check, and clean up code formatting in the ethtool stats collection. ==================== Signed-off-by: -
Shannon Nelson authored
Abstract out the per-queue data collection work into separate functions from the per-queue loops in the stats reporting, similar to what Alex did for the data label strings in commit acebe5b6 ("ionic: Update driver to use ethtool_sprintf") Signed-off-by:
Shannon Nelson <snelson@pensando.io> Signed-off-by:
-
Shannon Nelson authored
Rework the heartbeat checks to be sure that we're getting an atomic operation. Through testing we found occasions where a separate thread could clash with this check and cause erroneous heartbeat check results. Signed-off-by:
Allen Hubbe <allenbh@pensando.io> Signed-off-by:
-
Shannon Nelson authored
Use the actual pointer that we care about as the subject of the sizeof, rather than a struct name. Signed-off-by:
-
Shannon Nelson authored
Increment our dma-error counter in a couple of spots that were missed before. Signed-off-by:
-
David S. Miller authored
Ioana Ciornei says: ==================== dpaa2-switch: add STP support This patch set adds support for STP to the dpaa2-switch. First of all, it fixes a bug which was determined by the improper usage of bridge BR_STATE_* values directly in the MC ABI. The next patches deal with creating an ACL table per port and trapping the STP frames to the control interface by adding an entry into each table. The last patch configures proper learning state depending on the STP state. ==================== Signed-off-by: -
Ioana Ciornei authored
Depending on what STP state a port is in, the learning on that port should be enabled or disabled. When the STP state is DISABLED, BLOCKING or LISTENING no learning should be happening irrespective of what the bridge previously requested. The learning state is changed to be the one setup by the bridge when the STP state is LEARNING or FORWARDING. Signed-off-by:
Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by:
-
Ioana Ciornei authored
Add an ACL entry in each port's ACL table to redirect any frame that has the destination MAC address equal to the STP dmac to the control interface. Signed-off-by:
-
Ioana Ciornei authored
Keep track of the current learning state per port so that we can reference it in the next patches when setting up a STP state. Signed-off-by:
-
Ioana Ciornei authored
In order to trap frames to the CPU, the DPAA2 switch uses the ACL table. At probe time, create an ACL table for each switch port so that in the next patches we can use this to trap STP frames and redirect them to the control interface. Signed-off-by:
-
Ioana Ciornei authored
The numerical values used for STP states are different between the bridge and the MC ABI therefore, the direct usage of the BR_STATE_* macros directly in the structures passed to the firmware is incorrect. Create a separate function that translates between the bridge STP states and the enum that holds the STP state as seen by the Management Complex. Signed-off-by:
-
Vlad Buslov authored
Use act_simple to verify that action created with 'tc actions change' command exists after command returns. The goal is to verify internal action API reference counting to ensure that the case when netlink message has NLM_F_REPLACE flag set but action with specified index doesn't exist is handled correctly. Signed-off-by:
Vlad Buslov <vladbu@nvidia.com> Signed-off-by:
-
David S. Miller authored
Paolo Abeni says: ==================== udp: GRO L4 improvements This series improves the UDP L4 - either 'forward' or 'frag_list' - co-existence with UDP tunnel GRO, allowing the first to take place correctly even for encapsulated UDP traffic. The first for patches are mostly bugfixes, addressing some GRO edge-cases when both tunnels and L4 are present, enabled and in use. The next 3 patches avoid unneeded segmentation when UDP GRO traffic traverses in the receive path UDP tunnels. Finally, some self-tests are included, covering the relevant GRO scenarios. Even if most patches are actually bugfixes, this series is targeting net-next, as overall it makes available a new feature. v2 -> v3: - no code changes, more verbose commit messages and comment in patch 1/8 v1 -> v2: - restrict post segmentation csum fixup to the only the relevant pkts - use individual 'accept_gso_type' fields instead of whole gso bitmask (Willem) - use only ipv6 addesses from test range in self-tests (Willem) - hopefully clarified most individual patches commit messages ==================== Signed-off-by: -
Paolo Abeni authored
Create a bunch of virtual topologies and verify that NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD-enabled devices aggregate the ingress packets as expected. Additionally check that the aggregate packets are segmented correctly when landing on a socket Also test SKB_GSO_FRAGLIST and SKB_GSO_UDP_L4 aggregation on top of UDP tunnel (vxlan) v1 -> v2: - hopefully clarify the commit message - moved the overlay network ipv6 range into the 'documentation' reserved range (Willem) Signed-off-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Paolo Abeni authored
Similar to the previous commit, let even geneve passthrou the L4 GRO packets Signed-off-by:
-
Paolo Abeni authored
Similar to the previous commit, let even geneve passthrou the L4 GRO packets Signed-off-by:
-
Paolo Abeni authored
When passing up an UDP GSO packet with L4 aggregation, there is no need to segment it at the vxlan level. We can propagate the packet untouched and let it be segmented later, if needed. Introduce an helper to allow let the UDP socket to accept any L4 aggregation and use it in the vxlan driver. v1 -> v2: - updated to use the newly introduced UDP socket 'accept*' fields Signed-off-by:
-
Paolo Abeni authored
Currently the UDP protocol delivers GSO_FRAGLIST packets to the sockets without the expected segmentation. This change addresses the issue introducing and maintaining a couple of new fields to explicitly accept SKB_GSO_UDP_L4 or GSO_FRAGLIST packets. Additionally updates udp_unexpected_gso() accordingly. UDP sockets enabling UDP_GRO stil keep accept_udp_fraglist zeroed. v1 -> v2: - use 2 bits instead of a whole GSO bitmask (Willem) Fixes: 9fd1ff5d ("udp: Support UDP fraglist GRO/GSO.") Signed-off-by:
-
Paolo Abeni authored
After the previous patch, the stack can do L4 UDP aggregation on top of a UDP tunnel. In such scenario, udp{4,6}_gro_complete will be called twice. This function will enter its is_flist branch immediately, even though that is only correct on the second call, as GSO_FRAGLIST is only relevant for the inner packet. Instead, we need to try first UDP tunnel-based aggregation, if the GRO packet requires that. This patch changes udp{4,6}_gro_complete to skip the frag list processing when while encap_mark == 1, identifying processing of the outer tunnel header. Additionally, clears the field in udp_gro_complete() so that we can enter the frag list path on the next round, for the inner header. v1 -> v2: - hopefully clarified the commit message Reviewed-by: -
Paolo Abeni authored
If NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and there are UDP tunnels available in the system, udp_gro_receive() could end-up doing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) at the outer UDP tunnel level for packets effectively carrying and UDP tunnel header. That could cause inner protocol corruption. If e.g. the relevant packets carry a vxlan header, different vxlan ids will be ignored/ aggregated to the same GSO packet. Inner headers will be ignored, too, so that e.g. TCP over vxlan push packets will be held in the GRO engine till the next flush, etc. Just skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if the current packet could land in a UDP tunnel, and let udp_gro_receive() do GRO via udp_sk(sk)->gro_receive. The check implemented in this patch is broader than what is strictly needed, as the existing UDP tunnel could be e.g. configured on top of a different device: we could end-up skipping GRO at-all for some packets. Anyhow, that is a very thin corner case and covering it will add quite a bit of complexity. v1 -> v2: - hopefully clarify the commit message Fixes: 9fd1ff5d ("udp: Support UDP fraglist GRO/GSO.") Fixes: 36707061 ("udp: allow forwarding of plain (non-fraglisted) UDP GRO packets") Reviewed-by:
-
Paolo Abeni authored
When UDP packets generated locally by a socket with UDP_SEGMENT traverse the following path: UDP tunnel(xmit) -> veth (segmentation) -> veth (gro) -> UDP tunnel (rx) -> UDP socket (no UDP_GRO) ip_summed will be set to CHECKSUM_PARTIAL at creation time and such checksum mode will be preserved in the above path up to the UDP tunnel receive code where we have: __iptunnel_pull_header() -> skb_pull_rcsum() -> skb_postpull_rcsum() -> __skb_postpull_rcsum() The latter will convert the skb to CHECKSUM_NONE. The UDP GSO packet will be later segmented as part of the rx socket receive operation, and will present a CHECKSUM_NONE after segmentation. Additionally the segmented packets UDP CB still refers to the original GSO packet len. Overall that causes unexpected/wrong csum validation errors later in the UDP receive path. We could possibly address the issue with some additional checks and csum mangling in the UDP tunnel code. Since the issue affects only this UDP receive slow path, let's set a suitable csum status there. Note that SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST packets lacking an UDP encapsulation present a valid checksum when landing to udp_queue_rcv_skb(), as the UDP checksum has been validated by the GRO engine. v2 -> v3: - even more verbose commit message and comments v1 -> v2: - restrict the csum update to the packets strictly needing them - hopefully clarify the commit message and code comments Signed-off-by:
-
- 30 Mar, 2021 2 commits
-
-
Jiapeng Chong authored
Fix the following whitescan warning: Calling "zlib_inflateEnd(&state->strm)" is only useful for its return value, which is ignored. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by:
-
David S. Miller authored
Huazhong Tan says: ==================== net: remove repeated words This patch-set removes some repeated words in comments. ==================== Signed-off-by:
-
