- 31 Mar, 2021 40 commits
-
-
Brett Creeley authored
Currently ice_set/get_rss are used to set/get the RSS LUT and/or RSS key. However nearly everywhere these functions are called only the LUT or key are set/get. Also, making this change reduces how many things ice_set/get_rss are doing. Fix this by adding ice_set/get_rss_lut and ice_set/get_rss_key functions. Also, consolidate all calls for setting/getting the RSS LUT and RSS Key to use ice_set/get_rss_lut() and ice_set/get_rss_key(). Signed-off-by:
Brett Creeley <brett.creeley@intel.com> Tested-by:
Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com>
-
Brett Creeley authored
Update ice_aq_get_rss_lut() and ice_aq_set_rss_lut() to take a new structure ice_aq_get_set_rss_params instead of passing individual parameters. This is done for 2 reasons: 1. Reduce the number of parameters passed to the functions. 2. Reduce the amount of change required if the arguments ever need to be updated in the future. Also, reduce duplicate code that was checking for an invalid vsi_handle and lut parameter by moving the checks to the lower level __ice_aq_get_set_rss_lut(). Signed-off-by:
-
Brett Creeley authored
Currently, ice_vsi_setup_q_map() depends on the VSI's rss_size. However, the Rx Queue Mapping section of the VSI context has no dependency on RSS. Instead, limit the maximum number of Rx queues per TC based on the Rx Queue mapping section of the VSI context, which currently allows for up to 256 Rx queues per TC. Signed-off-by:
-
Qi Zhang authored
Align all ptype bitmap to follow ice_ptypes_xxx prefix. Signed-off-by:
Qi Zhang <qi.z.zhang@intel.com> Tested-by:
-
Bruce Allan authored
Use *malloc() instead of *calloc() when allocating only a single object as opposed to an array of objects. Signed-off-by:
Bruce Allan <bruce.w.allan@intel.com> Tested-by:
-
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:
-
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:
-
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:
-
