Re: [PATCH 08/10] qmi: Implement QMI service request rate limiting in 'can_write_data'.

Grant Erickson <[email protected]> Wed, 12 Feb 2025 16:07:58 -0800
Newsgroups dev.linux.lists.ofono
Message-ID <[email protected]>
On Feb 12, 2025, at 11:29 AM, Denis Kenzior <[email protected]> wrote:
> On 2/11/25 11:52 PM, Grant Erickson wrote:
>> Determine if we need to rate-limit QMI services requests to a
>> transport-specific minimum request period. If so, return true so that
>> the queue can be retried again later.
>> ---
>>  drivers/qmimodem/qmi.c | 17 +++++++++++++++++
>>  1 file changed, 17 insertions(+)
> 
> Patches 5, 6 and 8 should belong in the same commit.  Prefer to group new member definitions with their first use.

Noted. I’ll coalesce these in a v2 patch set.

>> diff --git a/drivers/qmimodem/qmi.c b/drivers/qmimodem/qmi.c
>> index 00086578da10..591129c252e3 100644
>> --- a/drivers/qmimodem/qmi.c
>> +++ b/drivers/qmimodem/qmi.c
>> @@ -665,8 +665,23 @@ static bool can_write_data(struct l_io *io, void *user_data)
>>  {
>>   struct qmi_transport *transport = user_data;
>>   struct qmi_request *req;
>> + const uint64_t now = l_time_now();
>> + uint64_t delta = 0;
>>   int r;
>>  + /*
>> + * Determine if we need to rate-limit commands to a
>> + * transport-specific minimum request period. If so,
>> + * return true so that the queue can be retried again
>> + * later.
>> + */
>> + if (transport->last_req_sent_time_us != 0) {
> 
> Shouldn't this check min_req_period_us first, before incurring l_time_now overhead?

I’d originally had this in a pre-submit draft. That’s a good optimization; noted for v2.

>> + delta = l_time_diff(now, transport->last_req_sent_time_us);
>> +
>> + if (delta < transport->min_req_period_us)
>> + return true;
>> + }
>> +
> 
> Something like:
> if (throttling_enabled) {
> now = l_time_now();
> delta = l_time_diff(now, transport->last_req_sent_time_us);
> 
> if (delta < min_req_period_us)
> return true;
> ^^^^ Note, that this is a poor approach since it just busy-loops the event-loop until the throttle time gate expires.  Much better would be to use some sort of timeout.

Noted. I’d debated a timeout / timer approach; however, it seemed much more complicated in terms of its impact on the send / dequeue path, so I went with this approach first to validate the concept.

Best,

Grant

-- 
Principal
Nuovations

[email protected]
https://www.nuovations.com/