#
54c9016e |
| 15-Aug-2023 |
Edward Cree <ecree.xilinx@gmail.com> |
sfc: don't fail probe if MAE/TC setup fails
Existing comment in the source explains why we don't want efx_init_tc() failure to be fatal. Cited commit erroneously consolidated failure paths causin
sfc: don't fail probe if MAE/TC setup fails
Existing comment in the source explains why we don't want efx_init_tc() failure to be fatal. Cited commit erroneously consolidated failure paths causing the probe to be failed in this case.
Fixes: 7e056e2360d9 ("sfc: obtain device mac address based on firmware handle for ef100") Reviewed-by: Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Link: https://lore.kernel.org/r/aa7f589dd6028bd1ad49f0a85f37ab33c09b2b45.1692114888.git.ecree.xilinx@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
d73e7715 |
| 27-Jul-2023 |
Martin Habets <habetsm.xilinx@gmail.com> |
sfc: Remove struct efx_special_buffer
The attributes index and entries are no longer needed, so use struct efx_buffer instead. next_buffer_table was also Siena specific. Removed some checkpatch warn
sfc: Remove struct efx_special_buffer
The attributes index and entries are no longer needed, so use struct efx_buffer instead. next_buffer_table was also Siena specific. Removed some checkpatch warnings.
Signed-off-by: Martin Habets <habetsm.xilinx@gmail.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
4aaf2c52 |
| 15-Jun-2023 |
Íñigo Huguet <ihuguet@redhat.com> |
sfc: use budget for TX completions
When running workloads heavy unbalanced towards TX (high TX, low RX traffic), sfc driver can retain the CPU during too long times. Although in many cases this is n
sfc: use budget for TX completions
When running workloads heavy unbalanced towards TX (high TX, low RX traffic), sfc driver can retain the CPU during too long times. Although in many cases this is not enough to be visible, it can affect performance and system responsiveness.
A way to reproduce it is to use a debug kernel and run some parallel netperf TX tests. In some systems, this will lead to this message being logged: kernel:watchdog: BUG: soft lockup - CPU#12 stuck for 22s!
The reason is that sfc driver doesn't account any NAPI budget for the TX completion events work. With high-TX/low-RX traffic, this makes that the CPU is held for long time for NAPI poll.
Documentations says "drivers can process completions for any number of Tx packets but should only process up to budget number of Rx packets". However, many drivers do limit the amount of TX completions that they process in a single NAPI poll.
In the same way, this patch adds a limit for the TX work in sfc. With the patch applied, the watchdog warning never appears.
Tested with netperf in different combinations: single process / parallel processes, TCP / UDP and different sizes of UDP messages. Repeated the tests before and after the patch, without any noticeable difference in network or CPU performance.
Test hardware: Intel(R) Xeon(R) CPU E5-1620 v4 @ 3.50GHz (4 cores, 2 threads/core) Solarflare Communications XtremeScale X2522-25G Network Adapter
Fixes: 5227ecccea2d ("sfc: remove tx and MCDI handling from NAPI budget consideration") Fixes: d19a53721863 ("sfc_ef100: TX path for EF100 NICs") Reported-by: Fei Liu <feliu@redhat.com> Signed-off-by: Íñigo Huguet <ihuguet@redhat.com> Acked-by: Martin Habets <habetsm.xilinx@gmail.com> Link: https://lore.kernel.org/r/20230615084929.10506-1-ihuguet@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
a59f832a |
| 17-Feb-2023 |
Arnd Bergmann <arnd@arndb.de> |
sfc: use IS_ENABLED() checks for CONFIG_SFC_SRIOV
One local variable has become unused after a recent change:
drivers/net/ethernet/sfc/ef100_nic.c: In function 'ef100_probe_netdev_pf': drivers/net/
sfc: use IS_ENABLED() checks for CONFIG_SFC_SRIOV
One local variable has become unused after a recent change:
drivers/net/ethernet/sfc/ef100_nic.c: In function 'ef100_probe_netdev_pf': drivers/net/ethernet/sfc/ef100_nic.c:1155:21: error: unused variable 'net_dev' [-Werror=unused-variable] struct net_device *net_dev = efx->net_dev; ^~~~~~~
The variable is still used in an #ifdef. Replace the #ifdef with an if(IS_ENABLED()) check that lets the compiler see where it is used, rather than adding another #ifdef.
This also fixes an uninitialized return value in ef100_probe_netdev_pf() that gcc did not spot.
Fixes: 7e056e2360d9 ("sfc: obtain device mac address based on firmware handle for ef100") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
fa78b017 |
| 15-Feb-2023 |
Alejandro Lucero <alejandro.lucero-palau@amd.com> |
sfc: add support for devlink port_function_hw_addr_get in ef100
Using the builtin client handle id infrastructure, add support for obtaining the mac address linked to mports in ef100. This implies t
sfc: add support for devlink port_function_hw_addr_get in ef100
Using the builtin client handle id infrastructure, add support for obtaining the mac address linked to mports in ef100. This implies to execute an MCDI command for getting the data from the firmware for each devlink port.
Signed-off-by: Alejandro Lucero <alejandro.lucero-palau@amd.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Acked-by: Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
show more ...
|
#
7e056e23 |
| 15-Feb-2023 |
Alejandro Lucero <alejandro.lucero-palau@amd.com> |
sfc: obtain device mac address based on firmware handle for ef100
Getting device mac address is currently based on a specific MCDI command only available for the PF. This patch changes the MCDI comm
sfc: obtain device mac address based on firmware handle for ef100
Getting device mac address is currently based on a specific MCDI command only available for the PF. This patch changes the MCDI command to a generic one for PFs and VFs based on a client handle. This allows both PFs and VFs to ask for their mac address during initialization using the CLIENT_HANDLE_SELF.
Moreover, the patch allows other client handles which will be used by the PF to ask for mac addresses linked to VFs. This is necessary for suporting the port_function_hw_addr_get devlink function in further patches.
Signed-off-by: Alejandro Lucero <alejandro.lucero-palau@amd.com> Acked-by: Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
show more ...
|
#
5227adff |
| 15-Feb-2023 |
Alejandro Lucero <alejandro.lucero-palau@amd.com> |
sfc: add mport lookup based on driver's mport data
Obtaining mport id is based on asking the firmware about it. This is still needed for mport initialization itself, but once the mport data is now k
sfc: add mport lookup based on driver's mport data
Obtaining mport id is based on asking the firmware about it. This is still needed for mport initialization itself, but once the mport data is now kept by the driver, further mport id request can be satisfied internally without firmware interaction.
Previous function is just modified in name making clear the firmware interaction. The new function uses the old name and looks for the data in the mport data structure.
Signed-off-by: Alejandro Lucero <alejandro.lucero-palau@amd.com> Acked-by: Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
show more ...
|
#
a6a15aca |
| 15-Feb-2023 |
Alejandro Lucero <alejandro.lucero-palau@amd.com> |
sfc: enumerate mports in ef100
MAE ports (mports) are the ports on the EF100 embedded switch such as networking PCIe functions, the physical port, and potentially others.
Signed-off-by: Alejandro L
sfc: enumerate mports in ef100
MAE ports (mports) are the ports on the EF100 embedded switch such as networking PCIe functions, the physical port, and potentially others.
Signed-off-by: Alejandro Lucero <alejandro.lucero-palau@amd.com> Acked-by: Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
show more ...
|
#
9dc0cad2 |
| 26-Sep-2022 |
Edward Cree <ecree.xilinx@gmail.com> |
sfc: bind blocks for TC offload on EF100
Bind direct blocks for the MAE-admin PF and each VF representor. Currently these connect to a stub efx_tc_flower() that only returns -EOPNOTSUPP; subsequent
sfc: bind blocks for TC offload on EF100
Bind direct blocks for the MAE-admin PF and each VF representor. Currently these connect to a stub efx_tc_flower() that only returns -EOPNOTSUPP; subsequent patches will implement flower offloads to the Match-Action Engine.
Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
e37f3b15 |
| 28-Jul-2022 |
Edward Cree <ecree.xilinx@gmail.com> |
sfc: use a dynamic m-port for representor RX and set it promisc
Representors do not want to be subject to the PF's Ethernet address filters, since traffic from VFs will typically have a destination
sfc: use a dynamic m-port for representor RX and set it promisc
Representors do not want to be subject to the PF's Ethernet address filters, since traffic from VFs will typically have a destination either elsewhere on the link segment or on an overlay network. So, create a dynamic m-port with promiscuous and all-multicast filters, and set it as the egress port of representor default rules. Since the m-port is an alias of the calling PF's own m-port, traffic will still be delivered to the PF's RXQs, but it will be subject to the VNRX filter rules installed on the dynamic m-port (specified by the v-port ID field of the filter spec).
Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
77eb4074 |
| 28-Jul-2022 |
Edward Cree <ecree.xilinx@gmail.com> |
sfc: move table locking into filter_table_{probe,remove} methods
We need to be able to drop the efx->filter_sem in ef100_filter_table_up() so that we can call functions that insert filters (and thu
sfc: move table locking into filter_table_{probe,remove} methods
We need to be able to drop the efx->filter_sem in ef100_filter_table_up() so that we can call functions that insert filters (and thus take that rwsem for read), which means the efx->type->filter_table_probe method needs to be responsible for taking the lock in the first place.
Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
67ab160e |
| 28-Jul-2022 |
Edward Cree <ecree.xilinx@gmail.com> |
sfc: insert default MAE rules to connect VFs to representors
Default rules are low-priority switching rules which the hardware uses in the absence of higher-priority rules. Each representor requir
sfc: insert default MAE rules to connect VFs to representors
Default rules are low-priority switching rules which the hardware uses in the absence of higher-priority rules. Each representor requires a corresponding rule matching traffic from its representee VF and delivering to the PF (where a check on INGRESS_MPORT in __ef100_rx_packet() will direct it to the representor). No rule is required in the reverse direction, because representor TX uses a TX override descriptor to bypass the MAE and deliver directly to the VF. Since inserting any rule into the MAE disables the firmware's own default rules, also insert a pair of rules to connect the PF to the physical network port and vice-versa.
Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
6f6838aa |
| 28-Jul-2022 |
Edward Cree <ecree.xilinx@gmail.com> |
sfc: determine wire m-port at EF100 PF probe time
Traffic delivered to the (MAE admin) PF could be from either the wire or a VF. The INGRESS_MPORT field of the RX prefix distinguishes these; base
sfc: determine wire m-port at EF100 PF probe time
Traffic delivered to the (MAE admin) PF could be from either the wire or a VF. The INGRESS_MPORT field of the RX prefix distinguishes these; base_mport is the value this field will have for traffic from the wire (which should be delivered to the PF's netdevice, not a representor).
Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
95287e1b |
| 20-Jul-2022 |
Edward Cree <ecree.xilinx@gmail.com> |
sfc: detect ef100 MAE admin privilege/capability at probe time
One PCIe function per network port (more precisely, per m-port group) is responsible for configuring the Match-Action Engine which per
sfc: detect ef100 MAE admin privilege/capability at probe time
One PCIe function per network port (more precisely, per m-port group) is responsible for configuring the Match-Action Engine which performs switching and packet modification in the slice to support flower/OVS offload. The GRP_MAE bit in the privilege mask indicates whether a given function has this capability. At probe time, call MCDIs to read the calling function's privilege mask, and store the GRP_MAE bit in a new ef100_nic_data member.
Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
98ff4c7c |
| 28-Jun-2022 |
Jonathan Cooper <jonathan.s.cooper@amd.com> |
sfc: Separate netdev probe/remove from PCI probe/remove
The netdev probe will be used when moving from vDPA to EF100 BAR config. The netdev remove will be used when moving from EF100 to vDPA BAR con
sfc: Separate netdev probe/remove from PCI probe/remove
The netdev probe will be used when moving from vDPA to EF100 BAR config. The netdev remove will be used when moving from EF100 to vDPA BAR config.
In the process, change several log messages to pci_ instead of netif_ to remove the "(unregistered net_device)" text.
Signed-off-by: Jonathan Cooper <jonathan.s.cooper@amd.com> Co-developed-by: Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by: Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
3e341d84 |
| 28-Jun-2022 |
Jonathan Cooper <jonathan.s.cooper@amd.com> |
sfc: Move EF100 efx_nic_type structs to the end of the file
This avoids a forward declaration in a subsequent patch.
Signed-off-by: Jonathan Cooper <jonathan.s.cooper@amd.com> Co-developed-by: Mart
sfc: Move EF100 efx_nic_type structs to the end of the file
This avoids a forward declaration in a subsequent patch.
Signed-off-by: Jonathan Cooper <jonathan.s.cooper@amd.com> Co-developed-by: Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by: Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
7c4e983c |
| 13-May-2022 |
Alexander Duyck <alexanderduyck@fb.com> |
net: allow gso_max_size to exceed 65536
The code for gso_max_size was added originally to allow for debugging and workaround of buggy devices that couldn't support TSO with blocks 64K in size. The o
net: allow gso_max_size to exceed 65536
The code for gso_max_size was added originally to allow for debugging and workaround of buggy devices that couldn't support TSO with blocks 64K in size. The original reason for limiting it to 64K was because that was the existing limits of IPv4 and non-jumbogram IPv6 length fields.
With the addition of Big TCP we can remove this limit and allow the value to potentially go up to UINT_MAX and instead be limited by the tso_max_size value.
So in order to support this we need to go through and clean up the remaining users of the gso_max_size value so that the values will cap at 64K for non-TCPv6 flows. In addition we can clean up the GSO_MAX_SIZE value so that 64K becomes GSO_LEGACY_MAX_SIZE and UINT_MAX will now be the upper limit for GSO_MAX_SIZE.
v6: (edumazet) fixed a compile error if CONFIG_IPV6=n, in a new sk_trim_gso_size() helper. netif_set_tso_max_size() caps the requested TSO size with GSO_MAX_SIZE.
Signed-off-by: Alexander Duyck <alexanderduyck@fb.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
ee8b7a11 |
| 06-May-2022 |
Jakub Kicinski <kuba@kernel.org> |
net: make drivers set the TSO limit not the GSO limit
Drivers should call the TSO setting helper, GSO is controllable by user space.
Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: D
net: make drivers set the TSO limit not the GSO limit
Drivers should call the TSO setting helper, GSO is controllable by user space.
Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
78a9b3c4 |
| 28-Apr-2022 |
Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com> |
sfc: add EF100 VF support via a write to sriov_numvfs
This patch extends the EF100 PF driver by adding .sriov_configure() which would allow users to enable and disable virtual functions using the sr
sfc: add EF100 VF support via a write to sriov_numvfs
This patch extends the EF100 PF driver by adding .sriov_configure() which would allow users to enable and disable virtual functions using the sriov sysfs.
Signed-off-by: Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com> Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Link: https://lore.kernel.org/r/75e74d9e-14ce-0524-9668-5ab735a7cf62@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
000fe940 |
| 31-Jan-2022 |
Martin Habets <habetsm.xilinx@gmail.com> |
sfc: The size of the RX recycle ring should be more flexible
Ideally the size would depend on the link speed, but the recycle ring is created when the interface is brought up before the driver knows
sfc: The size of the RX recycle ring should be more flexible
Ideally the size would depend on the link speed, but the recycle ring is created when the interface is brought up before the driver knows the link speed. So size it for the maximum speed of a given NIC. PowerPC is only supported on SFN7xxx and SFN8xxx NICs.
With this patch on a 40G NIC the number of calls to alloc_pages and friends went down from about 18% to under 2%. On a 10G NIC the number of calls to alloc_pages and friends went down from about 15% to 0 (perf did not capture any calls during the 60 second test). On a 100G NIC the number of calls to alloc_pages and friends went down from about 23% to 4%.
Reported-by: Íñigo Huguet <ihuguet@redhat.com> Signed-off-by: Martin Habets <habetsm.xilinx@gmail.com> Link: https://lore.kernel.org/r/20220131111054.cp4f6foyinaarwbn@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
407ecd1b |
| 15-Dec-2021 |
Jiasheng Jiang <jiasheng@iscas.ac.cn> |
sfc_ef100: potential dereference of null pointer
The return value of kmalloc() needs to be checked. To avoid use in efx_nic_update_stats() in case of the failure of alloc.
Fixes: b593b6f1b492 ("sfc
sfc_ef100: potential dereference of null pointer
The return value of kmalloc() needs to be checked. To avoid use in efx_nic_update_stats() in case of the failure of alloc.
Fixes: b593b6f1b492 ("sfc_ef100: statistics gathering") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
6d872df3 |
| 19-Nov-2021 |
Eric Dumazet <edumazet@google.com> |
net: annotate accesses to dev->gso_max_segs
dev->gso_max_segs is written under RTNL protection, or when the device is not yet visible, but is read locklessly.
Add netif_set_gso_max_segs() helper.
net: annotate accesses to dev->gso_max_segs
dev->gso_max_segs is written under RTNL protection, or when the device is not yet visible, but is read locklessly.
Add netif_set_gso_max_segs() helper.
Add the READ_ONCE()/WRITE_ONCE() pairs, and use netif_set_gso_max_segs() where we can to better document what is going on.
Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
4b66d216 |
| 19-Nov-2021 |
Eric Dumazet <edumazet@google.com> |
net: annotate accesses to dev->gso_max_size
dev->gso_max_size is written under RTNL protection, or when the device is not yet visible, but is read locklessly.
Add the READ_ONCE()/WRITE_ONCE() pairs
net: annotate accesses to dev->gso_max_size
dev->gso_max_size is written under RTNL protection, or when the device is not yet visible, but is read locklessly.
Add the READ_ONCE()/WRITE_ONCE() pairs, and use netif_set_gso_max_size() where we can to better document what is going on.
Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
a96d317f |
| 01-Oct-2021 |
Jakub Kicinski <kuba@kernel.org> |
ethernet: use eth_hw_addr_set()
Convert all Ethernet drivers from memcpy(... ETH_ADDR) to eth_hw_addr_set():
@@ expression dev, np; @@ - memcpy(dev->dev_addr, np, ETH_ALEN) + eth_hw_addr_
ethernet: use eth_hw_addr_set()
Convert all Ethernet drivers from memcpy(... ETH_ADDR) to eth_hw_addr_set():
@@ expression dev, np; @@ - memcpy(dev->dev_addr, np, ETH_ALEN) + eth_hw_addr_set(dev, np)
Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
c5122cf5 |
| 12-Nov-2020 |
Edward Cree <ecree@solarflare.com> |
sfc: support GRE TSO on EF100
We can treat SKB_GSO_GRE almost exactly the same as UDP tunnels, except that we don't want to edit the outer UDP len (as there isn't one). For SKB_GSO_GRE_CSUM, we hav
sfc: support GRE TSO on EF100
We can treat SKB_GSO_GRE almost exactly the same as UDP tunnels, except that we don't want to edit the outer UDP len (as there isn't one). For SKB_GSO_GRE_CSUM, we have to use GSO_PARTIAL as the device doesn't support offload of non-UDP outer L4 checksums.
Signed-off-by: Edward Cree <ecree@solarflare.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Acked-by: Martin Habets <mhabets@solarflare.com> Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
show more ...
|