Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2639599pxb; Tue, 9 Mar 2021 07:26:20 -0800 (PST) X-Google-Smtp-Source: ABdhPJxKycslHyyMYFNF5eJJREGPmaeCYKSkGAJTi3pUTd1AnBgffqMmhP36fF1/1NjSlMLqnG7z X-Received: by 2002:a17:906:3552:: with SMTP id s18mr21129118eja.497.1615303579999; Tue, 09 Mar 2021 07:26:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615303579; cv=none; d=google.com; s=arc-20160816; b=DrypiYgHSXHTmYgaQ0+imjbrRVtGXEBNkFUO0Wq6Q49+7e3y9q0naLSGousElsdlAg xl+Z8y9D4b67Cb4n5fvI58Io6rUBPoKVYFz2HCPiWn1hE2ccRjsbBfDMzSpS89D5LpL6 v/5I5Hk3D1DXY8p1Pf5VJ8W5ew3FfE8NoaUES1XfhVpRnybtxfpcB8Uqbjss29R9DSqL +iuxuH/2d5hYi8lAPjOQordOMIPAdqHWXP0z8Rco7vUwVjAv6HMvapeVsB7Y6f5WHky4 3RoxIE+paEna6n6xw+gZcXe/UWvDtaCspFEdV+SnAPrPvuc7v+0JexJ0G8zZYMbg9ELj 5wpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=JPJCrVQnITM05fgGJ+Es85/+rYh1LuCgyYd4/Cm51UU=; b=NTVljIWOaVAuw88FXzx+kYs+73joYt600MNCMnF6/tn4j9MqMzj47RxbQOMkwbXaeR 5bWnT6oMAbjhbTWFLuITmBNQJwO18HtrEtkRUA43a5qYv2xWY2pOQbMgBR5NcmhxmtYe KNKgwGsA9br5WVlcNBhwNbF219E7XKEbRpnQ7fTEuquTOlWumufN/aAc4Kp3le8xot3s NeAivWfuNW4aVfc6m3/C1qt+4O2F1UdqjSC2U7b4c/WaJnNPPinXymRpWAwp1W1Xh9TT qS4KbnnO+jxX+9UKSdvV2koCb64WmZazcg4lejKi3Oik6ia0dTOYaHVlg8/U6AjkfCPI IVPQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g15si9320844ejm.630.2021.03.09.07.25.56; Tue, 09 Mar 2021 07:26:19 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231410AbhCIPYu (ORCPT + 99 others); Tue, 9 Mar 2021 10:24:50 -0500 Received: from smtp02.smtpout.orange.fr ([80.12.242.124]:20140 "EHLO smtp.smtpout.orange.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231527AbhCIPYa (ORCPT ); Tue, 9 Mar 2021 10:24:30 -0500 Received: from localhost.localdomain ([153.202.107.157]) by mwinf5d20 with ME id eFQD2400T3PnFJp03FQMkA; Tue, 09 Mar 2021 16:24:28 +0100 X-ME-Helo: localhost.localdomain X-ME-Auth: bWFpbGhvbC52aW5jZW50QHdhbmFkb28uZnI= X-ME-Date: Tue, 09 Mar 2021 16:24:28 +0100 X-ME-IP: 153.202.107.157 From: Vincent Mailhol To: Marc Kleine-Budde , linux-can@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Tom Herbert , Eric Dumazet Cc: Peter Zijlstra , Randy Dunlap , Vincent Mailhol Subject: [RFC PATCH 0/1] Modify dql.min_limit value inside the driver Date: Wed, 10 Mar 2021 00:23:53 +0900 Message-Id: <20210309152354.95309-1-mailhol.vincent@wanadoo.fr> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 = ; > #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.ei75tr5vp2sanfh6@pengutronix.de/ Thank you for your comments. Yours sincerely, Vincent Vincent Mailhol (1): dql: add dql_set_min_limit() include/linux/dynamic_queue_limits.h | 3 +++ lib/dynamic_queue_limits.c | 8 ++++++++ 2 files changed, 11 insertions(+) -- 2.26.2