kernel/drivers/net/ethernet/sfc/tx.c, branch linux-6.18.y

sfc: Remove more unused functions

2024-11-06T01:35:11Z

efx_ticks_to_usecs(), efx_reconfigure_port(), efx_ptp_get_mode(), and efx_tx_get_copy_buffer_limited() are unused. They seem to be partially due to the later splits to Siena, but some seem unused for longer. Remove them. Signed-off-by: Dr. David Alan Gilbert Acked-by: Martin Habets Link: https://patch.msgid.link/20241102151625.39535-5-linux@treblig.org Signed-off-by: Jakub Kicinski

sfc: account XDP TXes in netdev base stats

2024-10-06T15:02:23Z

When we handle a TX completion for an XDP packet, it is not counted in the per-TXQ netdev stats. Record it in new internal counters, and include those in the device-wide total in efx_get_base_stats(). Signed-off-by: Edward Cree Signed-off-by: David S. Miller

sfc: Remove support for siena high priority queue

2023-07-28T08:54:17Z

This also removes TC support code, since that was never supported for EF10. TC support for EF100 is not handled from efx.c. Signed-off-by: Martin Habets Acked-by: Edward Cree Signed-off-by: David S. Miller

sfc: Use kmap_local_page() instead of kmap_atomic()

2022-11-25T10:44:01Z

kmap_atomic() is being deprecated in favor of kmap_local_page(). Replace kmap_atomic() and kunmap_atomic() with kmap_local_page() and kunmap_local() respectively. Note that kmap_atomic() disables preemption and page-fault processing, but kmap_local_page() doesn't. When converting uses of kmap_atomic(), one has to check if the code being executed between the map/unmap implicitly depends on page-faults and/or preemption being disabled. If yes, then code to disable page-faults and/or preemption should also be added for functional correctness. That however doesn't appear to be the case here, so just kmap_local_page() is used. Also note that the page being mapped is not allocated by the driver, and so the driver doesn't know if the page is in normal memory. This is the reason kmap_local_page() is used as opposed to page_address(). I don't have hardware, so this change has only been compile tested. Cc: Ira Weiny Cc: Fabio M. De Francesco Cc: Edward Cree Cc: Martin Habets Signed-off-by: Anirudh Venkataramanan Acked-by: Martin Habets Signed-off-by: David S. Miller

sfc: fix null pointer dereference in efx_hard_start_xmit

2022-09-20T01:09:55Z

Trying to get the channel from the tx_queue variable here is wrong because we can only be here if tx_queue is NULL, so we shouldn't dereference it. As the above comment in the code says, this is very unlikely to happen, but it's wrong anyway so let's fix it. I hit this issue because of a different bug that caused tx_queue to be NULL. If that happens, this is the error message that we get here: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [...] RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc] Fixes: 12804793b17c ("sfc: decouple TXQ type from label") Reported-by: Tianhao Zhao Signed-off-by: Íñigo Huguet Acked-by: Edward Cree Link: https://lore.kernel.org/r/20220914111135.21038-1-ihuguet@redhat.com Signed-off-by: Jakub Kicinski

sfc: support passing a representor to the EF100 TX path

2022-07-22T11:50:06Z

A non-null efv in __ef100_enqueue_skb() indicates that the packet is from that representor, should be transmitted with a suitable option descriptor (to instruct the switch to deliver it to the representee), and should not be accounted to the parent PF's stats or BQL. Signed-off-by: Edward Cree Signed-off-by: David S. Miller

sfc: Encapsulate access to netdev_priv()

2022-06-29T12:40:47Z

Once we separate struct efx_nic memory from net_device memory the existing usage will have to change. Apart from the new function efx_netdev_priv() accesses have been changed using: sed -i 's/netdev_priv/efx_netdev_priv/' Signed-off-by: Jonathan Cooper Co-developed-by: Martin Habets Signed-off-by: Martin Habets Signed-off-by: David S. Miller

sfc: use hardware tx timestamps for more than PTP

2022-04-08T21:43:10Z

The 8000 series and newer NICs all get hardware timestamps from the MAC and can provide timestamps on a normal TX queue, rather than via a slow path through the MC. As such we can use this path for any packet where a hardware timestamp is requested. This also enables support for PTP over transports other than IPv4+UDP. Signed-off-by: Bert Kenward Signed-off-by: Edward Cree Link: https://lore.kernel.org/r/510652dc-54b4-0e11-657e-e37ee3ca26a9@gmail.com Signed-off-by: Jakub Kicinski

net: sfc: fix using uninitialized xdp tx_queue

2022-04-06T12:50:17Z

In some cases, xdp tx_queue can get used before initialization. 1. interface up/down 2. ring buffer size change When CPU cores are lower than maximum number of channels of sfc driver, it creates new channels only for XDP. When an interface is up or ring buffer size is changed, all channels are initialized. But xdp channels are always initialized later. So, the below scenario is possible. Packets are received to rx queue of normal channels and it is acted XDP_TX and tx_queue of xdp channels get used. But these tx_queues are not initialized yet. If so, TX DMA or queue error occurs. In order to avoid this problem. 1. initializes xdp tx_queues earlier than other rx_queue in efx_start_channels(). 2. checks whether tx_queue is initialized or not in efx_xdp_tx_buffers(). Splat looks like: sfc 0000:08:00.1 enp8s0f1np1: TX queue 10 spurious TX completion id 250 sfc 0000:08:00.1 enp8s0f1np1: resetting (RECOVER_OR_ALL) sfc 0000:08:00.1 enp8s0f1np1: MC command 0x80 inlen 100 failed rc=-22 (raw=22) arg=789 sfc 0000:08:00.1 enp8s0f1np1: has been disabled Fixes: f28100cb9c96 ("sfc: fix lack of XDP TX queues - error XDP TX failed (-22)") Acked-by: Martin Habets Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller

sfc: last resort fallback for lack of xdp tx queues

2021-09-09T10:17:37Z

Previous patch addressed the situation of having some free resources for xdp tx but not enough for one tx queue per CPU. This patch address the worst case of not having resources at all for xdp tx. Instead of using queues dedicated to xdp, normal queues used by network stack are shared for both cases, using __netif_tx_lock for synchronization. Also queue stop/restart must be considered in the xdp path to avoid freezing the queue. This is not the ideal situation we might want to be, and a performance penalty is expected both for normal and xdp traffic, but at least XDP will work in all possible situations (with a warning in the logs), improving a bit the pain of not knowing in what situations we can use it and in what situations we cannot. Signed-off-by: Íñigo Huguet Signed-off-by: David S. Miller