summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet/mellanox
AgeCommit message (Collapse)AuthorFilesLines
2021-03-29mlxsw: spectrum: Veto sampling if already enabled on portIdo Schimmel1-0/+5
The per-port sampling triggers (i.e., ingress / egress) cannot be enabled twice. Meaning, the below configuration will not result in packets being sampled twice: # tc filter add dev swp1 ingress matchall skip_sw action sample rate 100 group 1 # tc filter add dev swp1 ingress matchall skip_sw action sample rate 100 group 1 Therefore, reject such configurations. Fixes: 90f53c53ec4a ("mlxsw: spectrum: Start using sampling triggers hash table") Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-29mlxsw: spectrum_matchall: Perform priority checks earlierIdo Schimmel1-18/+13
Perform the priority check earlier in the function instead of repeating it for every action. This fixes a bug that allowed matchall rules with sample action to be added in front of flower rules on egress. Fixes: 54d0e963f683 ("mlxsw: spectrum_matchall: Add support for egress sampling") Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-29mlxsw: spectrum_matchall: Convert if statements to a switch statementIdo Schimmel1-3/+6
Previous patch moved the protocol check out of the action check, so these if statements can now be converted to a switch statement. Perform the conversion. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-29mlxsw: spectrum_matchall: Perform protocol check earlierIdo Schimmel1-3/+7
Perform the protocol check earlier in the function instead of repeating it for every action. Example: # tc filter add dev swp1 ingress proto ip matchall skip_sw action sample group 1 rate 100 Error: matchall rules only supported with 'all' protocol. We have an error talking to the kernel Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-26net/mlx5: Fix spelling mistakes in mlx5_core_info messageColin Ian King1-1/+1
There are two spelling mistakes in a mlx5_core_info message. Fix them. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-03-26net/mlx5e: Cleanup PTPAya Levin2-16/+10
Reduce scope of mlx5e_ptp_params, move to its c file. Remove unneeded variables from mlx5e_ptp_open and state bitmap from PTP channel. In addition, remove channel index from PTP channel since it is set to a hard coded value, use define instead. Signed-off-by: Aya Levin <ayal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-03-26net/mlx5e: Generalize PTP implementationAya Levin8-62/+59
Following patches in the set add support for RX PTP. Rename PTP prefix from %s/port_ptp/ptp/g to include RX PTP too. In addition rename indication (used in statistics context) that PTP-SQ was opened: %s/port_ptp_opened/tx_ptp_opened/g. This will simplify adding indication that PTP-RQ was opened. Signed-off-by: Aya Levin <ayal@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-03-26net/mlx5e: Generalize direct-TIRs and direct-RQTs APIAya Levin4-36/+45
Add input parameter indicating the size of direct-TIRs/direct-RQTs array to be created/destroyed. This allows next patches in the patch-set to handle a single direct-TIR pointing to a direct-RQT with a single entry. Signed-off-by: Aya Levin <ayal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-03-26net/mlx5e: Generalize close RQAya Levin2-16/+9
Allow different flavours of RQ to use the same close flow. Add validity checks to support different RQ types which not necessarily initialize all the RQ's functionality. Signed-off-by: Aya Levin <ayal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-03-26net/mlx5e: Generalize RQ activationAya Levin2-14/+6
Support RQ activation for RQs without an ICOSQ in the main flow, like existing trap-RQ and like PTP-RQ that will be introduced in the coming patches in the patchset. With this patch, remove the wrapper in traps to deactivate the trap-RQ. Signed-off-by: Aya Levin <ayal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-03-26net/mlx5e: Generalize open RQAya Levin4-202/+147
Unify RQ creation for different RQ types. For each RQ type add a separate open helper which initializes the RQ specific values and trigger a call for generic open RQ function. Avoid passing the mlx5e_channel pointer to the generic open RQ as a container, since the RQ may reside under a different type of channel. Signed-off-by: Aya Levin <ayal@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-03-26net/mlx5: Add helper to set time-stamp translator on a queueAya Levin3-9/+14
Translation method on the time-stamp is set by the capabilities. Avoid code duplication by using a helper to set ptp_cyc2time callback on a queue. Signed-off-by: Aya Levin <ayal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-03-26net/mlx5e: Allow creating mpwqe info without channelAya Levin1-5/+4
Change the signature of mlx5e_rq_alloc_mpwqe_info from receiving channel pointer to receive the NUMA node. This allows creating mpwqe_info in context of different channels types. Signed-off-by: Aya Levin <ayal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-03-26net/mlx5e: Restrict usage of mlx5e_priv in params logic functionsTariq Toukan8-75/+77
Do not use generic struct mlx5e_priv as a parameter to param functions, as it is too generic. All calculations of the channel's param should be mainly based on struct mlx5_core_dev and struct mlx5e_params. Additional info can be explicitly passed. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Aya Levin <ayal@nvidia.com> Reviewed-by: Maxim Mikityanskiy <maximmi@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-03-26net/mlx5e: Move params logic into its dedicated fileTariq Toukan6-483/+497
Take params logic out of en_main.c, into the dedicated params.c. Some functions are now hidden and become static. No functional change here. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Maxim Mikityanskiy <maximmi@mellanox.com> Reviewed-by: Aya Levin <ayal@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-03-26net/mlx5e: Pass q_counter indentifier as parameter to rq_param buildersTariq Toukan4-7/+11
Pass q_counter idintifier, instead of reading it from mlx5e_priv parameter. This is a step towards removing the mlx5e_priv parameter from all params function and logic in the next patches of the series. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Aya Levin <ayal@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-03-26net/mlx5e: alloc the correct size for indirection_rqtSaeed Mahameed1-2/+2
The cited patch allocated the wrong size for the indirection_rqt table, fix that. Fixes: 2119bda642c4 ("net/mlx5e: allocate 'indirection_rqt' buffer dynamically") CC: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-03-26Merge https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller1-9/+6
Alexei Starovoitov says: ==================== pull-request: bpf-next 2021-03-24 The following pull-request contains BPF updates for your *net-next* tree. We've added 37 non-merge commits during the last 15 day(s) which contain a total of 65 files changed, 3200 insertions(+), 738 deletions(-). The main changes are: 1) Static linking of multiple BPF ELF files, from Andrii. 2) Move drop error path to devmap for XDP_REDIRECT, from Lorenzo. 3) Spelling fixes from various folks. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-26Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller21-81/+165
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25mlxsw: spectrum_router: Enable resilient nexthop groups to be programmedIdo Schimmel1-1/+85
Now that mlxsw supports resilient nexthop groups, allow them to be programmed after validating that their configuration conforms to the device's limitations (e.g., number of buckets is within predefined range). Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25mlxsw: spectrum_router: Periodically update activity of nexthop bucketsIdo Schimmel2-0/+102
The kernel periodically checks the idle time of nexthop buckets to determine if they are idle and can be re-populated with a new nexthop. When the resilient nexthop group is offloaded to hardware, the kernel will not see activity on nexthop buckets unless it is reported from hardware. Therefore, periodically (every 1 second) query the hardware for activity of adjacency entries used as part of a resilient nexthop group and report it to the nexthop code. The activity is only queried if resilient nexthop groups are in use. The delayed work is canceled otherwise. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25mlxsw: reg: Add Router Adjacency Table Activity Dump RegisterIdo Schimmel1-0/+55
The RATRAD register is used to dump and optionally clear activity bits of router adjacency table entries. Will be used by the next patch to query and clear the activity of nexthop buckets in a resilient nexthop group. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25mlxsw: spectrum_router: Update hardware flags on nexthop bucketsIdo Schimmel1-0/+37
So far, mlxsw only updated hardware flags ('offload' / 'trap') on nexthop objects. For resilient nexthop groups, these flags need to be updated on individual nexthop buckets as well. Update these flags whenever updating the flags of the encapsulating nexthop object and whenever a nexthop bucket is replaced. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25mlxsw: spectrum_router: Add nexthop bucket replacement supportIdo Schimmel1-0/+134
Replace a single nexthop bucket upon receiving a 'NEXTHOP_EVENT_BUCKET_REPLACE' notification. When the 'force' parameter is not set, instruct the device to only overwrite an adjacency entry if its activity is cleared, so as not to break existing flows using the adjacency entry. The device does not provide feedback if the replacement was successful in this case, so the contents of the adjacency entry after the replacement are compared with the replacement request. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25mlxsw: spectrum_router: Pass payload pointer to nexthop update functionIdo Schimmel5-17/+21
Have the caller pass a pointer to the payload of the RATR register to the function updating a single nexthop / adjacency entry. In a subsequent patch, this will allow the caller to make sure replacement was successful by querying the state of the adjacency entry after replacement and comparing with the initial request. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25mlxsw: spectrum_router: Add ability to overwrite adjacency entry only when ↵Ido Schimmel5-19/+32
inactive Allow the driver to instruct the device to only overwrite an adjacency entry if its activity is cleared. Currently, adjacency entry is always overwritten, regardless of activity. This will be used by subsequent patches to prevent replacement of active nexthop buckets. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-25mlxsw: spectrum_router: Add support for resilient nexthop groupsIdo Schimmel1-1/+25
Parse the configuration of resilient nexthop groups to existing mlxsw data structures. Unlike non-resilient groups, nexthops without a valid MAC or router interface (RIF) are programmed with a trap action instead of not being programmed at all. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24net: ethernet: Remove duplicate include of vhca_event.hWan Jiabing1-1/+0
vhca_event.h has been included at line 4, so remove the duplicate one at line 8. Signed-off-by: Wan Jiabing <wanjiabing@vivo.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24net: ethernet: indir_table.h is included twiceWan Jiabing1-1/+0
indir_table.h has been included at line 41, so remove the duplicate one at line 43. Signed-off-by: Wan Jiabing <wanjiabing@vivo.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Add Spectrum-{2, 3} adjacency group size rangesIdo Schimmel2-10/+32
Spectrum-{2,3} support different adjacency group size ranges compared to Spectrum-1. Add an array describing these ranges and change the common code to use the array which was set during the per-ASIC initialization. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Encode adjacency group size ranges in an arrayIdo Schimmel1-21/+44
The device supports a fixed set of adjacency group sizes. Encode these sizes in an array, so that the next patch will be able to split it between Spectrum-1 and Spectrum-{2,3}, which support different size ranges. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Create per-ASIC router operationsIdo Schimmel3-10/+41
There are several differences in the router module between Spectrum-1 and Spectrum-{2,3}. Currently, this is only apparent in the router interface (RIF) operations that are split between these ASICs. A subsequent patch is going to introduce another difference between these ASICs. Create per-ASIC router operations that will encapsulate all these differences. For now, these operations are only used to set the per-ASIC RIF operations in 'mlxsw_sp->router->rif_ops_arr'. Note that this fields was unused since commit 1f5b23033937 ("mlxsw: spectrum: Set RIF ops per ASIC type"). Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Avoid unnecessary neighbour updatesIdo Schimmel1-0/+4
Avoid updating neighbour and adjacency entries in hardware when the neighbour is already connected and its MAC address did not change. This can happen, for example, when neighbour transitions between valid states such as 'NUD_REACHABLE' and 'NUD_DELAY'. This is especially important for resilient hashing as these updates will result in adjacency entries being marked as active. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Break nexthop group entry validation to a separate ↵Ido Schimmel1-11/+25
function The validation of a nexthop group entry is also necessary for resilient nexthop groups, so break the validation to a separate function to allow for code reuse in subsequent patches. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Encapsulate nexthop update in a functionIdo Schimmel1-13/+15
Encapsulate this functionality in a separate function, so that it could be invoked by follow-up patches, when replacing a nexthop bucket that is part of a resilient nexthop group. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Rename nexthop update function to reflect its typeIdo Schimmel3-11/+14
mlxsw_sp_nexthop_update() is used to update the configuration of Ethernet-type nexthops, as opposed to mlxsw_sp_nexthop_ipip_update(), which is used to update IPinIP-type nexthops. Rename the function to mlxsw_sp_nexthop_eth_update(), so that it is consistent with mlxsw_sp_nexthop_ipip_update(). It will allow us to introduce mlxsw_sp_nexthop_update() in a follow-up patch, which calls either of above mentioned function based on the nexthop's type. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Add nexthop trap action supportIdo Schimmel1-13/+29
Currently, nexthops are programmed with either forward or discard action (for blackhole nexthops). Nexthops that do not have a valid MAC address (neighbour) or router interface (RIF) are simply not written to the adjacency table. In resilient nexthop groups, the size of the group must remain fixed and the kernel is in complete control of the layout of the adjacency table. A nexthop without a valid MAC or RIF will therefore be written with a trap action, to trigger neighbour resolution. Allow such nexthops to be programmed to the adjacency table to enable above mentioned use case. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Prepare for nexthops with trap actionIdo Schimmel1-1/+4
Nexthops that need to be programmed with a trap action might not have a valid router interface (RIF) associated with them. Therefore, use the loopback RIF created during initialization to program them to the device. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Introduce nexthop action fieldIdo Schimmel1-8/+17
Currently, the action associated with the nexthop is assumed to be 'forward' unless the 'discard' bit is set. Instead, simplify this by introducing a dedicated field to represent the action of the nexthop. This will allow us to more easily introduce more actions, such as trap. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Adjust comments on nexthop fieldsIdo Schimmel1-6/+6
The comments assume that nexthops are simple Ethernet nexthops that are programmed to forward packets to the associated neighbour. This is no longer the case, as both IPinIP and blackhole nexthops are now supported. Adjust the comments to reflect these changes. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Only provide MAC address for valid nexthopsIdo Schimmel1-1/+2
The helper returns the MAC address associated with the nexthop. It is only valid when the nexthop forwards packets and when it is an Ethernet nexthop. Reflect this in the checks the helper is performing. This is not an issue because the sole caller of the function only invokes it for such nexthops. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Consolidate nexthop helpersIdo Schimmel3-18/+9
The helper mlxsw_sp_nexthop_offload() is actually interested in finding out if the nexthop is both written to the adjacency table and forwarding packets (as opposed to discarding them). Rename it to mlxsw_sp_nexthop_is_forward() and remove mlxsw_sp_nexthop_is_discard(). Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Remove RTNL assertionIdo Schimmel1-2/+0
Remove the RTNL assertion in the nexthop notifier block. The assertion is not needed given RTNL is never assumed to be taken. This is a preparation for future patches where mlxsw will start handling nexthop events that are not always sent with RTNL held. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22net/mlx5: SF, do not use ecpu bit for vhca state processingParav Pandit4-24/+17
Device firmware doesn't handle ecpu bit for vhca state processing events and commands. Instead device firmware refers to the unique function id to distinguish SF of different PCI functions. When ecpu bit is used, firmware returns a syndrome. mlx5_cmd_check:780:(pid 872): MODIFY_VHCA_STATE(0xb0e) op_mod(0x0) failed, status bad parameter(0x3), syndrome (0x263211) mlx5_sf_dev_table_create:248:(pid 872): SF DEV table create err = -22 Hence, avoid using ecpu bit. Fixes: 8f0105418668 ("net/mlx5: SF, Add port add delete functionality") Fixes: 90d010b8634b ("net/mlx5: SF, Add auxiliary device support") Signed-off-by: Parav Pandit <parav@nvidia.com> Reviewed-by: Vu Pham <vuhuong@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-03-22net/mlx5e: Fix division by 0 in mlx5e_select_queueMaxim Mikityanskiy1-0/+5
mlx5e_select_queue compares num_tc_x_num_ch to real_num_tx_queues to determine if HTB and/or PTP offloads are active. If they are, it calculates netdev_pick_tx() % num_tc_x_num_ch to prevent it from selecting HTB and PTP queues for regular traffic. However, before the channels are first activated, num_tc_x_num_ch is zero. If ndo_select_queue gets called at this point, the HTB/PTP check will pass, and mlx5e_select_queue will attempt to take a modulo by num_tc_x_num_ch, which equals to zero. This commit fixes the bug by assigning num_tc_x_num_ch to a non-zero value before registering the netdev. Fixes: 214baf22870c ("net/mlx5e: Support HTB offload") Reported-by: Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-03-22net/mlx5e: Fix error path for ethtool set-priv-flagAya Levin1-1/+5
Expose error value when failing to comply to command: $ ethtool --set-priv-flags eth2 rx_cqe_compress [on/off] Fixes: be7e87f92b58 ("net/mlx5e: Fail safe cqe compressing/moderation mode setting") Signed-off-by: Aya Levin <ayal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-03-22net/mlx5e: Offload tuple rewrite for non-CT flowsDima Chumak2-12/+35
Setting connection tracking OVS flows and then setting non-CT flows that use tuple rewrite action (e.g. mod_tp_dst), causes the latter flows not being offloaded. Fix by using a stricter condition in modify_header_match_supported() to check tuple rewrite support only for flows with CT action. The check is factored out into standalone modify_tuple_supported() function to aid readability. Fixes: 7e36feeb0467 ("net/mlx5e: CT: Don't offload tuple rewrites for established tuples") Signed-off-by: Dima Chumak <dchumak@nvidia.com> Reviewed-by: Paul Blakey <paulb@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-03-22net/mlx5e: Allow to match on MPLS parameters only for MPLS over UDPAlaa Hleihel1-0/+10
Currently, we support hardware offload only for MPLS over UDP. However, rules matching on MPLS parameters are now wrongly offloaded for regular MPLS, without actually taking the parameters into consideration when doing the offload. Fix it by rejecting such unsupported rules. Fixes: 72046a91d134 ("net/mlx5e: Allow to match on mpls parameters") Signed-off-by: Alaa Hleihel <alaa@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-03-22net/mlx5: Add back multicast stats for uplink representorHuy Nguyen1-0/+7
The multicast counter got removed from uplink representor due to the cited patch. Fixes: 47c97e6b10a1 ("net/mlx5e: Fix multicast counter not up-to-date in "ip -s"") Signed-off-by: Huy Nguyen <huyn@nvidia.com> Reviewed-by: Daniel Jurgens <danielj@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-03-18bpf, devmap: Move drop error path to devmap for XDP_REDIRECTLorenzo Bianconi1-9/+6
We want to change the current ndo_xdp_xmit drop semantics because it will allow us to implement better queue overflow handling. This is working towards the larger goal of a XDP TX queue-hook. Move XDP_REDIRECT error path handling from each XDP ethernet driver to devmap code. According to the new APIs, the driver running the ndo_xdp_xmit pointer, will break tx loop whenever the hw reports a tx error and it will just return to devmap caller the number of successfully transmitted frames. It will be devmap responsibility to free dropped frames. Move each XDP ndo_xdp_xmit capable driver to the new APIs: - veth - virtio-net - mvneta - mvpp2 - socionext - amazon ena - bnxt - freescale (dpaa2, dpaa) - xen-frontend - qede - ice - igb - ixgbe - i40e - mlx5 - ti (cpsw, cpsw-new) - tun - sfc Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Camelia Groza <camelia.groza@nxp.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Acked-by: Jesper Dangaard Brouer <brouer@redhat.com> Acked-by: Shay Agroskin <shayagr@amazon.com> Link: https://lore.kernel.org/bpf/ed670de24f951cfd77590decf0229a0ad7fd12f6.1615201152.git.lorenzo@kernel.org
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-03 06:40:21 +0300