- 15 Nov, 2023 40 commits
-
-
Tariq Toukan authored
The netdev->features is initialized to netdev->hw_features at a later point in the flow. Remove any redundant earlier assignment. Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Reviewed-by:
Gal Pressman <gal@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com>
-
Or Har-Toov authored
Add counter for number of unicast, multicast and broadcast packets/ octets that were loopback. Signed-off-by:
Or Har-Toov <ohartoov@nvidia.com> Reviewed-by:
Patrisious Haddad <phaddad@nvidia.com> Signed-off-by:
-
Rahul Rameshbabu authored
Some mlx5 devices do not support the default advertised maximum frequency adjustment value for the PTP hardware clock that is set by the driver. These devices need to be queried when initializing the clock functionality in order to get the maximum supported frequency adjustment value. This value can be greater than the minimum supported frequency adjustment across mlx5 devices (50 million ppb). Signed-off-by:
Rahul Rameshbabu <rrameshbabu@nvidia.com> Reviewed-by:
-
Rahul Rameshbabu authored
Represent scaled ppm as ppb to the device when the value in scaled ppm is not representable as a 32-bit signed integer. mlx5 devices only support a 32-bit field for the frequency adjustment value in units of either scaled ppm or ppb. Since mlx5 devices only support a 32-bit field for the frequency adjustment value independent of unit used, limit the maximum frequency adjustment to S32_MAX ppb. Signed-off-by:
-
Rahul Rameshbabu authored
Configure the PHC inside mlx5_init_timer_clock for calling mlx5_ptp_settime later in the function. Would previously use mlx5_ptp_clock_info instance to invoke mlx5_ptp_settime to set the NIC real-time clock to be synchronized with the host system clock. Signed-off-by:
-
Rahul Rameshbabu authored
Check if the MTUTC register of the NIC can be modified before attempting to execute a real-time clock operation. Previous implementation aborted the real-time clock operation pre-emptively when the MTUTC register used to control the real-time clock was not modifiable, indicating real-time clock mode was not enabled on the NIC. The original control flow was confusing since the noop-if-RTC-disabled branch looked similar to an error handling guard clause. The purpose of this patch is purely for improving readability and should lead to no functional change. Signed-off-by:
-
Gal Pressman authored
Access the headers array using pedit_cmd enum values, and don't assume anything about their values. Signed-off-by:
Vlad Buslov <vladbu@nvidia.com> Signed-off-by:
-
Justin Stitt authored
In total, just assigning this version string takes: (1) strncpy()'s (5) strlen()'s (3) strncat()'s (1) snprintf()'s (4) max_t()'s Moreover, `strncpy` is deprecated [1] and `strncat` really shouldn't be used either [2]. With this in mind, let's simply use a single `snprintf`. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://elixir.bootlin.com/linux/v6.6-rc5/source/include/linux/fortify-string.h#L448 [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Cc: Kees Cook <keescook@chromium.org> Signed-off-by:
Justin Stitt <justinstitt@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Kees Cook authored
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct mlx5_flow_handle. Cc: Saeed Mahameed <saeedm@nvidia.com> Cc: Leon Romanovsky <leon@kernel.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: netdev@vger.kernel.org Cc: linux-rdma@vger.kernel.org Link: https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci [1] Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Signed-off-by:
-
Kees Cook authored
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct mlx5_fc_bulk. Cc: Saeed Mahameed <saeedm@nvidia.com> Cc: Leon Romanovsky <leon@kernel.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: netdev@vger.kernel.org Cc: linux-rdma@vger.kernel.org Link: https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci [1] Signed-off-by:
-
Amir Tzin authored
Function mlx5e_tc_stats_matchall() is only called from one file: drivers/net/ethernet/mellanox/mlx5/core/en/rep/tc.c Move it there and make it static as exposing it is unnecessary. Also variable cur_stats is redundant. Remove it and avoid superfluous copy. This patch does not change functionality. Reviewed-by:
Amir Tzin <amirtz@nvidia.com> Signed-off-by:
-
Moshe Shemesh authored
In sync reset flow, PF is checking that only devices of same device ID as itself present on the PCIe bridge, otherwise it will NACK the reset. Since the PCIe bridge connection to NIC card has to be 1 to 1, this is valid. However, the BlueField device may also expose another sub-device to the PCI called management interface, which only provides an ethernet channel between the host and the smart NIC. Allow sync reset flow also when management interface sub-device present when checking devices on the PCIe bridge. Signed-off-by:
Moshe Shemesh <moshe@nvidia.com> Signed-off-by:
-
Moshe Shemesh authored
While collecting crdump as part of fw_fatal health reporter dump the PF may fail to lock the SW reset semaphore. Change the print to indicate if it was due to another PF locked the semaphore already and so trying to lock the semaphore returned -EBUSY. Signed-off-by:
Shay Drory <shayd@nvidia.com> Signed-off-by:
-
Jakub Kicinski authored
The top syzbot report for networking (#14 for the entire kernel) is the queue timeout splat. We kept it around for a long time, because in real life it provides pretty strong signal that something is wrong with the driver or the device. Removing it is also likely to break monitoring for those who track it as a kernel warning. Nevertheless, WARN()ings are best suited for catching kernel programming bugs. If a Tx queue gets starved due to a pause storm, priority configuration, or other weirdness - that's obviously a problem, but not a problem we can fix at the kernel level. Bite the bullet and convert the WARN() to a print. Before: NETDEV WATCHDOG: eni1np1 (netdevsim): transmit queue 0 timed out 1975 ms WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:525 dev_watchdog+0x39e/0x3b0 [... completely pointless stack trace of a timer follows ...] Now: netdevsim netdevsim1 eni1np1: NETDEV WATCHDOG: CPU: 0: transmit queue 0 timed out 1769 ms Alternatively we could mark the drivers which syzbot has learned to abuse as "print-instead-of-WARN" selectively. Reported-by: syzbot+d55372214aff0faa1f1f@syzkaller.appspotmail.com Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Michael Chan says: ==================== bnxt_en: TX path improvements All patches in this patchset are related to improving the TX path. There are 2 areas of improvements: 1. The TX interrupt logic currently counts the number of TX completions to determine the number of TX SKBs to free. We now change it so that the TX completion will now contain the hardware consumer index information. The driver will keep track of the latest hardware consumer index from the last TX completion and clean up all TX SKBs up to that index. This scheme aligns better with future chips and allows xmit_more code path to be more optimized. 2. The current driver logic requires an additional MSIX for each additional MQPRIO TX ring. This scheme uses too many MSIX vectors if the user enables a large number of MQPRIO TCs. We now use a new scheme that will use the same MSIX for all the MQPRIO TX rings for each ethtool channel. Each ethtool TX channel can have up to 8 MQPRIO TX rings and now they all will share the same MSIX. v2: Rebased v1 posted on Oct 27 2023 right before the close of net-next: https://lore.kernel.org/netdev/20231027232252.36111-1-michael.chan@broadcom.com/ ==================== Signed-off-by:
-
Michael Chan authored
Now that we use the cumulative consumer index scheme for TX completion, we don't need to have one TX completion per TX packet in the xmit_more code path. Set the TX_BD_FLAGS_NO_CMPL flag if xmit_more is true. Fallback to one interrupt per packet if the ring is filled beyond bp->tx_wake_thresh. Also, move the wmb() to bnxt_txr_db_kick(). When xmit_more is true, we'll skip the bnxt_txr_db_kick() call and there is no need to call wmb() to sync. the TX BD data. Reviewed-by:
Somnath Kotur <somnath.kotur@broadcom.com> Reviewed-by:
Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Michael Chan authored
We can now fully support sharing the same MSIX for all mqprio TX rings belonging to the same ethtool channel with the new infrastructure: 1. Allocate the proper entries for cp_ring_arr in struct bnxt_cp_ring_info to support the additional TX rings. 2. Populate the tx_ring array in struct bnxt_napi for all TX rings sharing the same NAPI. 3. bnxt_num_tx_to_cp() returns the proper NQ/completion rings to support the TX rings in the input. 4. Adjust bnxt_get_num_ring_stats() for the reduced number of ring counters with the new scheme. Reviewed-by:
Andy Gospodarek <andrew.gospodarek@broadcom.com> Signed-off-by:
-
Michael Chan authored
Add 3 macros that handle to conversions between TC numbers and TX ring numbers. These will help to clarify the existing logic and the new logic in the next patch. Reviewed-by:
-
Michael Chan authored
Up until now, each TX ring always requires a completion ring/NQ/MSIX. bnxt_trim_rings() and the assignment of bp->cp_nr_rings always make this assumption. This will no longer be true in the next patches, so we refactor and add helper functions to determine the proper relationship between TX rings and the required completion ring/NQ/MSIX. This patch does not change the 1:1 relationship yet. Note that on P5 chips, each RX and TX ring still requires a completion ring. Only the number of NQs has been reduced. We should no longer call bnxt_trim_rings() to adjust the RX and TX rings on P5 chips. Replace with simple logic to check that RX + TX < CP and adjust accordingly. bnxt_check_rings() should call _bnxt_get_max_rings() to get the raw number of rings instead of bnxt_get_max_rings(). If we are about to create TCs, bnxt_get_max_rings() would not be able to calculate the max rings correctly. Reviewed-by:
-
Michael Chan authored
For each mqprio TC, we allocate a set of TX rings to map to the new hardware CoS queue. Expand the tx_ring pointer in struct bnxt_napi to an array of 8 to support up to 8 TX rings, one for each TC. Only array entry 0 is used at this time. The rest of the array entries will be used in later patches. Reviewed-by:
-
Michael Chan authored
Add 2 helper functions to set coalescing for each RX and TX rings. This will make it easier to expand the number of TX rings per MSIX in the next patches. Reviewed-by:
-
Michael Chan authored
In order to support multiple TX rings on the same MSIX, we'll use the upper byte of the TX opaque field to store the ring index in the new tx_napi_idx field. This tx_napi_idx field is currently always 0 until more infrastructure is added in later patches. Reviewed-by:
-
Michael Chan authored
bnxt_tx_int() processes the only one TX ring from the bnxt_napi pointer. To prepare for more TX rings associated with the bnxt_napi structure, add a new __bnxt_tx_int() function that takes the bnxt_tx_ring_info pointer to process that one TX ring. No functional change. Reviewed-by:
-
Michael Chan authored
These 2 constants were used for the one RX and one TX completion ring pointer in the cpr->cp_ring_arr fixed array. Now that we've changed to allocating the array for the exact number of entries to support more TX rings, we no longer use these constants. The array index as well as the type of completion ring (RX/TX) are now encoded in the handle for the completion ring. This will allow us to locate the completion ring during NAPI for any number of completion rings sharing the same MSIX. In the following patches, we'll be adding support for more TX rings associated with the same MSIX vector. Reviewed-by:
-
Michael Chan authored
From the TX or RX ring structure, we need to find the corresponding completion ring during initialization. On P5 chips, we use the MSIX/napi entry to locate the completion ring because there is only one RX/TX ring per MSIX. To allow multiple TX rings for each MSIX, we need to add a direct pointer from the TX ring and RX ring structures. This also simplifies the existing logic. Reviewed-by:
-
Michael Chan authored
The cp_ring_arr is currently a fixed array of 2 pointers for the TX and RX completion rings. These pointers are allocated during ring initialization. Currntly, we support up to 2 completion rings for each MSIX. In order to support more completion rings, we change this fixed array to a pointer and allocate the required entries during ring initialization. This patch keeps the current scheme of allocating only 2 entries when needed. Later patches will expand and allocate more entries when required. Reviewed-by:
-
Michael Chan authored
From the TX or RX ring structure, we need to find the corresponding completion ring during initialization. On P5 chips, we use the MSIX/napi entry to locate the completion ring because there is only one RX/TX ring per MSIX. To allow multiple TX rings for each MSIX, we need to add a direct pointer from the TX ring and RX ring structures. This also simplifies the existing logic. Reviewed-by:
-
Michael Chan authored
Currently, the opaque field in the TX BD is only used for debugging. The TX completion logic relies on getting one TX completion for each packet and they always complete in order. Improve this scheme by putting the producer information (ring index plus number of BDs for the packet) in the opaque field. This way, we can handle TX completion processing by looking at the last TX completion instead of counting the number of completions. Since we no longer need to count the exact number of completions, we can optimize xmit_more by disabling TX completion when the xmit_more condition is true. This will be done in later patches. This patch is only initializing the opaque field in the TX BD and is not changing the driver's TX completion logic yet. Reviewed-by:
Andy Gospodarek <gospo@broadcom.com> Signed-off-by:
-
Jakub Kicinski authored
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2023-11-13 (i40e) This series contains updates to i40e driver only. Justin Bronder increases number of allowable descriptors for XL710 devices. Su Hui adds error check, and unroll, for RSS configuration. Andrii changes module read error message to debug and makes it more verbose. Ivan Vecera performs numerous clean-ups and refactors to driver such as removing unused defines and fields, converting use of flags to bitmaps, adding helpers, re-organizing code, etc. ==================== Link: https://lore.kernel.org/r/20231113231047.548659-1-anthony.l.nguyen@intel.comSigned-off-by:
-
Ivan Vecera authored
From commit 9eed69a9 ("i40e: Drop FCoE code from core driver files") the field i40e_mac_info.san_addr is unused (never filled). The field i40e_mac_info.max_fcoeq is unused from the beginning. Remove both. Reviewed-by:
Wojciech Drewek <wojciech.drewek@intel.com> Co-developed-by:
Michal Schmidt <mschmidt@redhat.com> Signed-off-by:
Ivan Vecera <ivecera@redhat.com> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://lore.kernel.org/r/20231113231047.548659-16-anthony.l.nguyen@intel.comSigned-off-by:
-
Ivan Vecera authored
Move version check helper functions from i40e_type.h to i40e_prototype.h as per discussion [1]. [1] https://lore.kernel.org/all/cdcd6b97-1138-4cd7-854f-b3faa1f475f8@intel.com/#t Cc: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
-
Ivan Vecera authored
The i40e_hw.mac.type cannot to be equal to I40E_MAC_VF or I40E_MAC_X722_VF so remove helper i40e_is_vf(), simplify i40e_adminq_init_regs() and remove enums for these VF MAC types. Signed-off-by:
-
Ivan Vecera authored
Use new helpers to check versions of running FW and provided AQ API to make the code more readable. Signed-off-by:
-
Ivan Vecera authored
Add another helper functions that will be used by subsequent patch to refactor existing open-coded checks whether the version of running firmware and AdminQ API is recent enough to provide certain capabilities. Signed-off-by:
-
Ivan Vecera authored
Move i40e_is_aq_api_ver_ge helper function (used to check if AdminQ API version is recent enough) to header so it can be used from other .c files. Signed-off-by:
-
Ivan Vecera authored
Some i40e_hw.caps bits are set in i40e_set_hw_caps(), some of them in i40e_init_adminq() and the rest of them in i40e_sw_init(). Consolidate the initialization to single proper place i40e_set_hw_caps(). Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by:
-
Ivan Vecera authored
Fields .caps in i40e_hw and .hw_features in i40e_pf both indicate capabilities provided by hardware. Move and merge i40e_pf.hw_features into i40e_hw.caps as this is more appropriate place for them and adjust their names to I40E_HW_CAP_... convention. Signed-off-by:
-
Ivan Vecera authored
Convert flags field in i40e_hw from u64 to bitmap and its usage to use bit access functions and rename the field to 'caps' as this field describes capabilities that are set once on init and read many times later. Changes: - Convert "hw_ptr->flags & FLAG" to "test_bit(FLAG, ...)" - Convert "hw_ptr->flags |= FLAG" to "set_bit(FLAG, ...)" - Convert "hw_ptr->flags &= ~FLAG" to "clear_bit(FLAG, ...)" - Rename i40e_hw.flags to i40e_hw.caps - Rename i40e_set_hw_flags() to i40e_set_hw_caps() - Adjust caps names so they are prefixed by I40E_HW_CAP_ and existing _CAPABLE suffixes are stripped Signed-off-by:
-
Ivan Vecera authored
Convert flags and hw_features fields from i40e_pf from u32 to bitmaps and their usage to use bit access functions. Changes: - Convert "pf_ptr->(flags|hw_features) & FL" to "test_bit(FL, ...)" - Convert "pf_ptr->(flags|hw_features) |= FL" to "set_bit(FL, ...)" - Convert "pf_ptr->(flags|hw_features) &= ~FL" to "clear_bit(FL, ...)" - Rename flag field to bitno in i40e_priv_flags and adjust ethtool callbacks to work with flags bitmap - Rename flag names where '_ENABLED'->'_ENA' and '_DISABLED'->'_DIS' like in ice driver Signed-off-by:
-
Ivan Vecera authored
Enum type names should not be suffixed by '_t'. Either to use 'typedef enum name name_t' to so plain 'name_t var' instead of 'enum name_t var'. Signed-off-by:
-
