On 11/5/20 5:47 AM, Vincent MAILHOL wrote: >>> Okay, we can take this as a quick fix but to me it seems a little >>> strange to be dropping what is effectively locally generated frames. > > For those who are not familiar with SocketCAN and to make sure that we > are all aligned here, let me give a bit of context of how the echo on CAN > skbs is usually implement in the drivers: > * In the xmit() branch, the driver would queue the skb using > can_put_echo_skb(). > * Whenever the driver gets notified of a successful TX, it will loopback > the skb using can_get_echo_skb(). > > This is why the loopback is usually done in hardware IRQ context (but > drivers are also free to skip the second step and directly loopback the > skb in the xmit() branch). > >> Thanks! So this patch doesn't hinder Marc's PR :-) >> >>> Can we use a NAPI poll model here and back pressure TX if the echo >>> is not keeping up? >> >> Some of the CAN network drivers already support NAPI. And some drivers (i.e. flexcan and mcp251xfd) already queue the ech_skb via NAPI. > I had a quick look at NAPI in the past and my understanding is that it > requires the ability to turn off hardware interrupts meaning that it can > be only used on some NIC, not but not, for example, on USB devices. > > It would be nice to extend the NAPI with skb loopback for drivers which > already supports it but I am not sure how to include the other drivers. > >> @Marc: Can we also use NAPI for echo'ing the skbs? The flexcan driver does: https://elixir.bootlin.com/linux/v5.10-rc2/source/drivers/net/can/flexcan.c#L1080 In the interrupt handler, the driver pushes the echo_skb into the rx-offload queue and triggers NAPI. The rx-offload pushed the skb into the networking stack via NAPI. Here the code in the mcp251xfd driver: https://elixir.bootlin.com/linux/v5.10-rc2/source/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c#L1237 Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: OpenPGP digital signature
