#
a9ca9f9c |
|
04-Aug-2023 |
Yunsheng Lin <linyunsheng@huawei.com> |
page_pool: split types and declarations from page_pool.h Split types and pure function declarations from page_pool.h and add them in page_page/types.h, so that C sources can include page_pool.h and headers should generally only include page_pool/types.h as suggested by jakub. Rename page_pool.h to page_pool/helpers.h to have both in one place. Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> Suggested-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com> Reviewed-by: Alexander Duyck <alexanderduyck@fb.com> Link: https://lore.kernel.org/r/20230804180529.2483231-2-aleksander.lobakin@intel.com [Jakub: change microsoft/mana, fix kdoc paths in Documentation] Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
700f11eb |
|
22-Apr-2023 |
Horatiu Vultur <horatiu.vultur@microchip.com> |
lan966x: Don't use xdp_frame when action is XDP_TX When the action of an xdp program was XDP_TX, lan966x was creating a xdp_frame and use this one to send the frame back. But it is also possible to send back the frame without needing a xdp_frame, because it is possible to send it back using the page. And then once the frame is transmitted is possible to use directly page_pool_recycle_direct as lan966x is using page pools. This would save some CPU usage on this path, which results in higher number of transmitted frames. Bellow are the statistics: Frame size: Improvement: 64 ~8% 256 ~11% 512 ~8% 1000 ~0% 1500 ~0% Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Link: https://lore.kernel.org/r/20230422142344.3630602-1-horatiu.vultur@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
ff89ac70 |
|
17-Mar-2023 |
Horatiu Vultur <horatiu.vultur@microchip.com> |
net: lan966x: Don't read RX timestamp if not needed Whenever a frame was received to the CPU, the HW is timestamping the frame. In the IFH(Inter Frame Header) it is found the nanosecond part of the timestamps the SW is required to read from HW the second part. But reading the second part it seems to be a expensive operations, so so change this such to read the second part only when rx filter is enabled. Doing this change gives the RX a performance boost of ~70mbit. before: [ 5] 0.00-10.01 sec 546 MBytes 457 Mbits/sec 0 sender now: [ 5] 0.00-10.01 sec 652 MBytes 530 Mbits/sec 0 sender Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
12b57179 |
|
25-Jan-2023 |
Magnus Karlsson <magnus.karlsson@intel.com> |
lan966x: execute xdp_do_flush() before napi_complete_done() Make sure that xdp_do_flush() is always executed before napi_complete_done(). This is important for two reasons. First, a redirect to an XSKMAP assumes that a call to xdp_do_redirect() from napi context X on CPU Y will be followed by a xdp_do_flush() from the same napi context and CPU. This is not guaranteed if the napi_complete_done() is executed before xdp_do_flush(), as it tells the napi logic that it is fine to schedule napi context X on another CPU. Details from a production system triggering this bug using the veth driver can be found following the first link below. The second reason is that the XDP_REDIRECT logic in itself relies on being inside a single NAPI instance through to the xdp_do_flush() call for RCU protection of all in-kernel data structures. Details can be found in the second link below. Fixes: a825b611c7c1 ("net: lan966x: Add support for XDP_REDIRECT") Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com> Acked-by: Toke Høiland-Jørgensen <toke@redhat.com> Acked-by: Steen Hegelund <Steen.Hegelund@microchip.com> Link: https://lore.kernel.org/r/20221220185903.1105011-1-sbohrer@cloudflare.com Link: https://lore.kernel.org/all/20210624160609.292325-1-toke@redhat.com/ Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
a825b611 |
|
23-Nov-2022 |
Horatiu Vultur <horatiu.vultur@microchip.com> |
net: lan966x: Add support for XDP_REDIRECT Extend lan966x XDP support with the action XDP_REDIRECT. This is similar with the XDP_TX, so a lot of functionality can be reused. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
19c6f534 |
|
23-Nov-2022 |
Horatiu Vultur <horatiu.vultur@microchip.com> |
net: lan966x: Add support for XDP_TX Extend lan966x XDP support with the action XDP_TX. In this case when the received buffer needs to execute XDP_TX, the buffer will be moved to the TX buffers. So a new RX buffer will be allocated. When the TX finish with the frame, it would give back the buffer to the page pool. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
560c7223 |
|
23-Nov-2022 |
Horatiu Vultur <horatiu.vultur@microchip.com> |
net: lan966x: Update dma_dir of page_pool_params To add support for XDP_TX it is required to be able to write to the DMA area therefore it is required that the pages will be mapped using DMA_BIDIRECTIONAL flag. Therefore check if there are any xdp programs on the interfaces and in that case set DMA_BIDRECTIONAL otherwise use DMA_FROM_DEVICE. Therefore when a new XDP program is added it is required to redo the page_pool. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
77ddda44 |
|
23-Nov-2022 |
Horatiu Vultur <horatiu.vultur@microchip.com> |
net: lan966x: Update rxq memory model By default the rxq memory model is MEM_TYPE_PAGE_SHARED but to be able to reuse pages on the TX side, when the XDP action XDP_TX it is required to update the memory model to PAGE_POOL. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
49f5eea8 |
|
23-Nov-2022 |
Horatiu Vultur <horatiu.vultur@microchip.com> |
net: lan966x: Add len field to lan966x_tx_dcb_buf Currently when a frame was transmitted, it is required to unamp the frame that was transmitted. The length of the frame was taken from the transmitted skb. In the future we might not have an skb, therefore store the length skb directly in the lan966x_tx_dcb_buf and use this one to unamp the frame. While at this, also arrange the members in lan966x_tx_dcb_buf not to have any holes. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
3d66bc57 |
|
23-Nov-2022 |
Horatiu Vultur <horatiu.vultur@microchip.com> |
net: lan966x: Introduce helper functions Introduce lan966x_fdma_tx_setup_dcb and lan966x_fdma_tx_start functions and use of them inside lan966x_fdma_xmit. There is no functional change in here. They are introduced to be used when XDP_TX/REDIRECT actions are introduced. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
7292bb06 |
|
23-Nov-2022 |
Horatiu Vultur <horatiu.vultur@microchip.com> |
net: lan966x: Add XDP_PACKET_HEADROOM Update the page_pool params to allocate XDP_PACKET_HEADROOM space as headroom for all received frames. This is needed for when the XDP_TX and XDP_REDIRECT are implemented. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
11871aba |
|
09-Nov-2022 |
Horatiu Vultur <horatiu.vultur@microchip.com> |
net: lan96x: Use page_pool API Use the page_pool API for allocation, freeing and DMA handling instead of dev_alloc_pages, __free_pages and dma_map_page. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
6a2159be |
|
09-Nov-2022 |
Horatiu Vultur <horatiu.vultur@microchip.com> |
net: lan966x: Add basic XDP support Introduce basic XDP support to lan966x driver. Currently the driver supports only the actions XDP_PASS, XDP_DROP and XDP_ABORTED. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
4a00b0c7 |
|
09-Nov-2022 |
Horatiu Vultur <horatiu.vultur@microchip.com> |
net: lan966x: Split function lan966x_fdma_rx_get_frame The function lan966x_fdma_rx_get_frame was unmapping the frame from device and check also if the frame was received on a valid port. And only after that it tried to generate the skb. Move this check in a different function, in preparation for xdp support. Such that xdp to be added here and the lan966x_fdma_rx_get_frame to be used only when giving the skb to upper layers. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
e83163b6 |
|
09-Nov-2022 |
Horatiu Vultur <horatiu.vultur@microchip.com> |
net: lan966x: Add define IFH_LEN_BYTES The total length of IFH(inter frame header) in bytes is calculated as IFH_LEN * sizeof(u32). Because IFH_LEN describes the length in words and not in bytes. As the length of IFH in bytes is used quite often, add a define for this. This is just to simplify the things. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
fc57062f |
|
31-Oct-2022 |
Horatiu Vultur <horatiu.vultur@microchip.com> |
net: lan966x: Fix unmapping of received frames using FDMA When lan966x was receiving a frame, then it was building the skb and after that it was calling dma_unmap_single with frame size as the length. This actually has 2 issues: 1. It is using a length to map and a different length to unmap. 2. When the unmap was happening, the data was sync for cpu but it could be that this will overwrite what build_skb was initializing. The fix for these two problems is to change the order of operations. First to sync the frame for cpu, then to build the skb and in the end to unmap using the correct size but without sync the frame again for cpu. Fixes: c8349639324a ("net: lan966x: Add FDMA functionality") Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Link: https://lore.kernel.org/r/20221031133421.1283196-1-horatiu.vultur@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
872ad758 |
|
30-Oct-2022 |
Horatiu Vultur <horatiu.vultur@microchip.com> |
net: lan966x: Fix FDMA when MTU is changed When MTU is changed, FDMA is required to calculate what is the maximum size of the frame that it can received. So it can calculate what is the page order needed to allocate for the received frames. The first problem was that, when the max MTU was calculated it was reading the value from dev and not from HW, so in this way it was missing L2 header + the FCS. The other problem was that once the skb is created using __build_skb_around, it would reserve some space for skb_shared_info. So if we received a frame which size is at the limit of the page order then the creating will failed because it would not have space to put all the data. Fixes: 2ea1cbac267e ("net: lan966x: Update FDMA to change MTU.") Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
4a4b6848 |
|
21-Oct-2022 |
Horatiu Vultur <horatiu.vultur@microchip.com> |
net: lan966x: Stop replacing tx dcbs and dcbs_buf when changing MTU When a frame is sent using FDMA, the skb is mapped and then the mapped address is given to an tx dcb that is different than the last used tx dcb. Once the HW finish with this frame, it would generate an interrupt and then the dcb can be reused and memory can be freed. For each dcb there is an dcb buf that contains some meta-data(is used by PTP, is it free). There is 1 to 1 relationship between dcb and dcb_buf. The following issue was observed. That sometimes after changing the MTU to allocate new tx dcbs and dcbs_buf, two frames were not transmitted. The frames were not transmitted because when reloading the tx dcbs, it was always presuming to use the first dcb but that was not always happening. Because it could be that the last tx dcb used before changing MTU was first dcb and then when it tried to get the next dcb it would take dcb 1 instead of 0. Because it is supposed to take a different dcb than the last used one. This can be fixed simply by changing tx->last_in_use to -1 when the fdma is disabled to reload the new dcb and dcbs_buff. But there could be a different issue. For example, right after the frame is sent, the MTU is changed. Now all the dcbs and dcbs_buf will be cleared. And now get the interrupt from HW that it finished with the frame. So when we try to clear the skb, it is not possible because we lost all the dcbs_buf. The solution here is to stop replacing the tx dcbs and dcbs_buf when changing MTU because the TX doesn't care what is the MTU size, it is only the RX that needs this information. Fixes: 2ea1cbac267e ("net: lan966x: Update FDMA to change MTU.") Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Link: https://lore.kernel.org/r/20221021090711.3749009-1-horatiu.vultur@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
b48b89f9 |
|
27-Sep-2022 |
Jakub Kicinski <kuba@kernel.org> |
net: drop the weight argument from netif_napi_add We tell driver developers to always pass NAPI_POLL_WEIGHT as the weight to netif_napi_add(). This may be confusing to newcomers, drop the weight argument, those who really need to tweak the weight can use netif_napi_add_weight(). Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> # for CAN Link: https://lore.kernel.org/r/20220927132753.750069-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
13a9d08c |
|
26-Aug-2022 |
Dan Carpenter <dan.carpenter@oracle.com> |
net: lan966x: improve error handle in lan966x_fdma_rx_get_frame() Don't just print a warning. Clean up and return an error as well. Fixes: c8349639324a ("net: lan966x: Add FDMA functionality") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com> Link: https://lore.kernel.org/r/YwjgDm/SVd5c1tQU@kili Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
f0a65f81 |
|
11-May-2022 |
Horatiu Vultur <horatiu.vultur@microchip.com> |
net: lan966x: Fix use of pointer after being freed The smatch found the following warning: drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c:736 lan966x_fdma_reload() warn: 'rx_dcbs' was already freed. This issue can happen when changing the MTU on one of the ports and once the RX buffers are allocated and then the TX buffer allocation fails. In that case the RX buffers should not be restore. This fix this issue such that the RX buffers will not be restored if the TX buffers failed to be allocated. Fixes: 2ea1cbac267e2a ("net: lan966x: Update FDMA to change MTU.") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Link: https://lore.kernel.org/r/20220511204059.2689199-1-horatiu.vultur@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
2ea1cbac |
|
08-Apr-2022 |
Horatiu Vultur <horatiu.vultur@microchip.com> |
net: lan966x: Update FDMA to change MTU. When changing the MTU, it is required to change also the size of the DBs. In case those frames will arrive to CPU. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
c8349639 |
|
08-Apr-2022 |
Horatiu Vultur <horatiu.vultur@microchip.com> |
net: lan966x: Add FDMA functionality Ethernet frames can be extracted or injected to or from the device's DDR memory. There is one channel for injection and one channel for extraction. Each of these channels contain a linked list of DCBs which contains DB. The DCB contains only 1 DB for both the injection and extraction. Each DB contains a frame. Every time when a frame is received or transmitted an interrupt is generated. It is not possible to use both the FDMA and the manual injection/extraction of the frames. Therefore the FDMA has priority over the manual because of better performance values. FDMA: iperf -c 192.168.1.1 [ 5] 0.00-10.02 sec 420 MBytes 352 Mbits/sec 0 sender [ 5] 0.00-10.03 sec 420 MBytes 351 Mbits/sec receiver iperf -c 192.168.1.1 -R [ 5] 0.00-10.01 sec 528 MBytes 442 Mbits/sec 0 sender [ 5] 0.00-10.00 sec 524 MBytes 440 Mbits/sec receiver Manual: iperf -c 192.168.1.1 [ 5] 0.00-10.02 sec 93.8 MBytes 78.5 Mbits/sec 0 sender [ 5] 0.00-10.03 sec 93.8 MBytes 78.4 Mbits/sec receiver ipers -c 192.168.1.1 -R [ 5] 0.00-10.03 sec 121 MBytes 101 Mbits/sec 0 sender [ 5] 0.00-10.01 sec 118 MBytes 99.0 Mbits/sec receiver Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|