- 22 Mar, 2021 40 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueDavid S. Miller authored
Tony Nguyen says: ==================== 100GbE Intel Wired LAN Driver Updates 2021-03-22 This series contains updates to ice and iavf drivers. Haiyue Wang says: The Intel E810 Series supports a programmable pipeline for a domain specific protocols classification, for example GTP by Dynamic Device Personalization (DDP) profile. The E810 PF has introduced flex-bytes support by ethtool user-def option allowing for packet deeper matching based on an offset and value for DDP usage. For making VF also benefit from this flexible protocol classification, some new virtchnl messages are defined and handled by PF, so VF can query this new flow director capability, and use ethtool with extending the user-def option to configure Rx flow classification. The new user-def 0xAAAABBBBCCCCDDDD: BBBB is the 2 byte pattern while AAAA corresponds to its offset in the packet. Similarly DDDD is the 2 byte pattern with CCCC being the corresponding offset. The offset ranges from 0x0 to 0x1F7 (up to 504 bytes into the packet). The offset starts from the beginning of the packet. This feature can be used to allow customers to set flow director rules for protocols headers that are beyond standard ones supported by ethtool (e.g. PFCP or GTP-U). Like for matching GTP-U's TEID value 0x10203040: ethtool -N ens787f0v0 flow-type udp4 dst-port 2152 \ user-def 0x002e102000303040 action 13 ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Preparations for resilient nexthop groups This patchset contains preparations for resilient nexthop groups support in mlxsw. A follow-up patchset will add support and selftests. Most of the patches are trivial and small to make review easier. Patchset overview: Patch #1 removes RTNL assertion in nexthop notifier block since it is not needed. The assertion will trigger when mlxsw starts processing notifications related to resilient groups as not all are emitted with RTNL held. Patches #2-#9 gradually add support for nexthops with trap action. Up until now mlxsw did not program nexthops whose neighbour entry was not resolved. This will not work with resilient groups as their size is fixed and the nexthop mapped to each bucket is determined by the nexthop code. Therefore, nexthops whose neighbour entry is not resolved will be programmed to trap packets to the CPU in order to trigger neighbour resolution. Patch #10 is a non-functional change to allow for code reuse between regular nexthop groups and resilient ones. Patch #11 avoids unnecessary neighbour updates in hardware. See the commit message for a detailed explanation. Patches #12-#14 add support for additional nexthop group sizes that are supported by Spectrum-{2,3} ASICs. ==================== Signed-off-by: -
Ido Schimmel authored
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:
-
Ido Schimmel authored
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 authored
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 1f5b2303 ("mlxsw: spectrum: Set RIF ops per ASIC type"). Signed-off-by: -
Ido Schimmel authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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:
-
Nikolay Aleksandrov authored
Recently we had an interop issue where RARP packets got suppressed with bridge neigh suppression enabled, but the check in the code was meant to suppress GARP. Exclude RARP packets from it which would allow some VMWare setups to work, to quote the report: "Those RARP packets usually get generated by vMware to notify physical switches when vMotion occurs. vMware may use random sip/tip or just use sip=tip=0. So the RARP packet sometimes get properly flooded by the vtep and other times get dropped by the logic" Reported-by:
Amer Abdalamer <amer@nvidia.com> Signed-off-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
-
Antoine Tenart authored
xps_queue_show is mostly made of an RCU read-side critical section and calls bitmap_zalloc with GFP_KERNEL in the middle of it. That is not allowed as this call may sleep and such behaviours aren't allowed in RCU read-side critical sections. Fix this by using GFP_NOWAIT instead. Fixes: 5478fcd0 ("net: embed nr_ids in the xps maps") Reported-by:
kernel test robot <oliver.sang@intel.com> Suggested-by:
Matthew Wilcox <willy@infradead.org> Signed-off-by:
Antoine Tenart <atenart@kernel.org> Signed-off-by:
-
Wei Yongjun authored
Get rid of the CONFIG_PM_SLEEP ifdefery to fix the build error and use __maybe_unused for the suspend()/resume() hooks to avoid build warning: drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:769:21: error: 'stmmac_runtime_suspend' undeclared here (not in a function); did you mean 'stmmac_suspend'? 769 | SET_RUNTIME_PM_OPS(stmmac_runtime_suspend, stmmac_runtime_resume, NULL) | ^~~~~~~~~~~~~~~~~~~~~~ ./include/linux/pm.h:342:21: note: in definition of macro 'SET_RUNTIME_PM_OPS' 342 | .runtime_suspend = suspend_fn, \ | ^~~~~~~~~~ drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:769:45: error: 'stmmac_runtime_resume' undeclared here (not in a function) 769 | SET_RUNTIME_PM_OPS(stmmac_runtime_suspend, stmmac_runtime_resume, NULL) | ^~~~~~~~~~~~~~~~~~~~~ ./include/linux/pm.h:343:20: note: in definition of macro 'SET_RUNTIME_PM_OPS' 343 | .runtime_resume = resume_fn, \ | ^~~~~~~~~ Fixes: 5ec55823 ("net: stmmac: add clocks management for gmac driver") Reported-by:Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
Bhaskar Chowdhury authored
s/verifed/verified/ Signed-off-by:
Bhaskar Chowdhury <unixbhaskar@gmail.com> Acked-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Arnd Bergmann authored
gcc warns about a pointless condition: drivers/isdn/hardware/mISDN/hfcmulti.c: In function 'hfcmulti_interrupt': drivers/isdn/hardware/mISDN/hfcmulti.c:2752:17: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body] 2752 | ; /* external IRQ */ As the check has no effect, just remove it. Suggested-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Signed-off-by:
-
Vladimir Oltean authored
ptype_all and ptype_base are declared in net/core/dev.c as non-static, because they are used by net-procfs.c too. However, a "make W=1" build complains that there was no previous declaration of ptype_all and ptype_base in a header file, so this way of declaring things constitutes a violation of coding style. Let's move the extern declarations of ptype_all and ptype_base to the linux/netdevice.h file, which is included by net-procfs.c too. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Vladimir Oltean authored
Since their introduction in commit 04157469 ("net: Use static_key for XPS maps"), xps_needed and xps_rxqs_needed were never used outside net/core/dev.c, so I don't really understand why they were exported as symbols in the first place. This is needed in order to silence a "make W=1" warning about these static keys not being declared as static variables, but not having a previous declaration in a header file nonetheless. Cc: Amritha Nambiar <amritha.nambiar@intel.com> Signed-off-by:
-
Vladimir Oltean authored
The only caller of br_vlan_tunnel_lookup, br_handle_ingress_vlan_tunnel, extracts the tunnel_id from struct ip_tunnel_info::struct ip_tunnel_key:: tun_id which is a __be64 value. The exact endianness does not seem to matter, because the tunnel id is just used as a lookup key for the VLAN group's tunnel hash table, and the value is not interpreted directly per se. Moreover, rhashtable_lookup_fast treats the key argument as a const void *. Therefore, there is no functional change associated with this patch, just one to silence "make W=1" builds. Signed-off-by:
-
Jiapeng Chong authored
Fix the following coccicheck warnings: ./drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c:3540:2-8: WARNING: NULL check before some freeing functions is not needed. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by:
-
Vladimir Oltean authored
Commit 0b529448 ("net: dsa: mv88e6xxx: scratch: Fixup kerneldoc") has addressed some but not all kerneldoc warnings for the Global 2 Scratch register accessors. Namely, we have some mismatches between the function names in the kerneldoc and the ones in the actual code. Let's adjust the comments so that they match the functions they're sitting next to. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
David S. Miller authored
Michael Chan says: ==================== bnxt_en: Error recovery improvements. This series contains some improvements for error recovery. The main changes are: 1. Keep better track of the health register mappings with the "status_reliable" flag. 2. Don't wait for firmware responses if firmware is not healthy. 3. Better retry logic of the first firmware message. 4. Set the proper flag early to let the RDMA driver know that firmware reset has been detected. ==================== Signed-off-by: -
Michael Chan authored
Two enhancements: 1. Read the health status first before sending the first HWRM_VER_GET message to firmware instead of the other way around. This guarantees we got the accurate health status before we attempt to send the message. 2. We currently only retry sending the first HWRM_VER_GET message to the firmware if the firmware is in the process of booting. If the firmware is in error state and is doing core dump for example, the driver should also retry if the health register has the RECOVERING flag set. This flag indicates the firmware will undergo recovery soon. Modify the retry logic to retry for this case as well. Reviewed-by:
Edwin Peer <edwin.peer@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Vasundhara Volam authored
Once the chip goes through reset, the register mapping may be lost and any read of the mapped health registers may return garbage value until the registers are mapped again in the init path. Reading BNXT_FW_RESET_INPROG_REG after firmware reset will likely return garbage value due to the above reason. Reading this register is for information purpose only so remove it. Reviewed-by:
Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by:
-
Michael Chan authored
During ifup, if the driver detects that firmware has gone through a reset, it will go through a re-probe sequence. If the RDMA driver is loaded, the re-probe sequence includes calling the RDMA driver to stop. We need to set the BNXT_STATE_FW_RESET_DET flag earlier so that it is visible to the RDMA driver. The RDMA driver's stop sequence is different if firmware has gone through a reset. Reviewed-by:
Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by:
P B S Naresh Kumar <nareshkumar.pbs@broadcom.com> Signed-off-by:
-
Scott Branden authored
Check return value of call to bnxt_hwrm_func_resc_qcaps in bnxt_hwrm_if_change and return failure on error. Reviewed-by:
Scott Branden <scott.branden@broadcom.com> Signed-off-by:
-
Edwin Peer authored
The original intent here is to allow commands during reset to succeed without error when the device is disabled, to ensure that cleanup completes normally during NIC close, where firmware is not necessarily expected to respond. The problem with faking success during reset's PCI disablement is that unrelated ULP commands will also see inadvertent success during reset when failure would otherwise be appropriate. It is better to return a different error result such that reset related code can detect this unique condition and ignore as appropriate. Note, the pci_disable_device() when firmware is fatally wounded in bnxt_fw_reset_close() does not need to be addressed, as subsequent commands are already expected to fail due to the BNXT_NO_FW_ACCESS() check in bnxt_hwrm_do_send_msg(). Reviewed-by:
-
Pavan Chebbi authored
In situations where FW has crashed, the bnxt_hwrm_do_send_msg() call will have to wait until timeout for each firmware message. This generally takes about half a second for each firmware message. If we try to unload the driver n this state, the unload sequence will take a long time to complete. Improve this by checking the health register if it is available and abort the wait for the firmware response if the register shows that firmware is not healthy. The very first message HWRM_VER_GET is excluded from this check because that message is used to poll for firmware to come out of reset during error recovery. Signed-off-by:
-
Michael Chan authored
In order to read the firmware health status, we first need to determine the register location and then the register may need to be mapped. There are 2 code paths to do this. The first one is done early as a best effort attempt by the function bnxt_try_map_fw_health_reg(). The second one is done later in the function bnxt_map_fw_health_regs() after establishing communications with the firmware. We currently only set fw_health->status_reliable if we can successfully set up the health register in the first code path. Improve the scheme by setting the fw_health->status_reliable flag if either (or both) code paths can successfully set up the health register. This flag is relied upon during run-time when we need to check the health status. So this will make it work better. During ifdown, if the health register is mapped, we need to invalidate the health register mapping because a potential fw reset will reset the mapping. Similarly, we need to do the same after firmware reset during recovery. We'll remap it during ifup. Reviewed-by:
-
David S. Miller authored
Huazhong Tan says: ==================== net: hns3: refactor and new features for flow director This patchset refactor some functions and add some new features for flow director. patch 1~3: refactor large functions patch 4, 7: add traffic class and user-def field support for ethtool patch 5: refactor flow director configuration patch 6: clean up for hns3_del_all_fd_entries() change log: V1->V2: modifies patch 5 as Jakub suggested, keep configuring ethtool/tc flower rules synchronously while aRFS asynchronously. changes the usecnt of user-def rule checking in patch 7. removes previous patches 8 and 9 from this series, since there are issues that need further discussion. ==================== Signed-off-by: -
Jian Shen authored
For DEVICE_VERSION_V3, the hardware supports to match specified data in the specified offset of packet payload. Each layer can have one offset, and can't be masked when configure flow director rule by ethtool command. The layer is selected based on the flow-type, ether for L2, ip4/ipv6 for L3, and tcp4/tcp6/udp4/udp6 for L4. For example, tcp4/tcp6/udp4/udp6 rules share the same user-def offset, but each rule can have its own user-def value. For the user-def field of ethtool -N/U command is 64 bits long. The bit 0~15 is used for user-def value, and bit 32~47 for user-def offset in HNS3 driver. Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Jian Shen authored
For only PF driver can configure flow director rule, it's better to call hclge_del_all_fd_entries() directly in hclge layer, rather than call hns3_del_all_fd_entries() in hns3 layer. Then the ae_algo->ops.del_all_fd_entries can be removed. Signed-off-by:
-
Jian Shen authored
Currently, the flow director rule of aRFS is configured in the IO path. It's time-consuming. So move out the configuration, and configure it asynchronously. And keep ethtool and tc flower rule using synchronous way, otherwise the application maybe unable to know the rule is installed or pending. Add a state member for each flow director rule to indicate the rule state. There are 4 states: TO_ADD: the rule is waiting to add to hardware TO_DEL: the rule is waiting to remove from hardware DELETED: the rule has been removed from hardware. It's a middle state, used to remove the rule node in the fd_rule_list. ACTIVE: the rule is already added in hardware For asynchronous way, when receive a new request to add or delete flow director rule by aRFS, update the rule list, then request to schedule the service task to finish the configuration. For synchronous way, when receive a new request to add or delete flow director rule by ethtool or tc flower, configure hardware directly, then update the rule list if success. Signed-off-by: -
Jian Shen authored
The hardware supports to parse and match the traffic class field of IPv6 packet for flow director, uses the same tuple as ip tos. So removes the limitation of configure 'tclass' by driver. Signed-off-by:
-
Jian Shen authored
Currently, there are too many branches for hclge_fd_convert_tuple(). And it may be more when add new tuples. Refactor it by sorting the tuples according to their length. So it only needs several KEY_OPT now, and being flexible to add new tuples. Signed-off-by:
-
