Abstract: would like to directly set dql.min_limit value inside a driver to improve BQL performances of a CAN USB driver.
CAN packets have a small PDU: for classical CAN maximum size is roughly 16 bytes (8 for payload and 8 for arbitration, CRC and others). I am writing an CAN driver for an USB interface. To compensate the extra latency introduced by the USB, I want to group several CAN frames and do one USB bulk send. To this purpose, I implemented BQL in my driver. However, the BQL algorithms can take time to adjust, especially if there are small bursts. The best way I found is to directly modify the dql.min_limit and set it to some empirical values. This way, even during small burst events I can have a good throughput. Slightly increasing the dql.min_limit has no measurable impact on the latency as long as frames fit in the same USB packet (i.e. BQL overheard is negligible compared to USB overhead). The BQL was not designed for USB nor was it designed for CAN's small PDUs which probably explains why I am the first one to ever have thought of using dql.min_limit within the driver. The code I wrote looks like: > #ifdef CONFIG_BQL > netdev_get_tx_queue(netdev, 0)->dql.min_limit = <some empirical value>; > #endif Using #ifdef to set up some variables is not a best practice. I am sending this RFC to see if we can add a function to set this dql.min_limit in a more pretty way. For your reference, this RFQ is a follow-up of a discussion on the linux-can mailing list: https://lore.kernel.org/linux-can/20210309125708.ei75tr5vp2san...@pengutronix.de/ Thank you for your comments. Yours sincerely, Vincent ** Changelog ** RFC v1 -> RFC v2 - Fix incorect #ifdef use. Reference: https://lore.kernel.org/linux-can/20210309153547.q7zspf46k6ter...@pengutronix.de/ Link to RFC v1: https://lore.kernel.org/linux-can/20210309152354.95309-1-mailhol.vinc...@wanadoo.fr/T/#t Vincent Mailhol (1): dql: add dql_set_min_limit() include/linux/netdevice.h | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) -- 2.26.2
