netdev - Re: [PATCH net-next v4] net: qualcomm: rmnet: Add side band flow control support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <0a2595e5-972b-e73e-6221-85c37419ac6b@quicinc.com>
Date: Tue, 10 Oct 2023 18:35:37 -0600
From: "Subash Abhinov Kasiviswanathan (KS)" <quic_subashab@...cinc.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: <davem@...emloft.net>, <edumazet@...gle.com>, <pabeni@...hat.com>,
        <netdev@...r.kernel.org>, <vadim.fedorenko@...ux.dev>, <lkp@...el.com>,
        <horms@...nel.org>, Sean Tranchetti <quic_stranche@...cinc.com>
Subject: Re: [PATCH net-next v4] net: qualcomm: rmnet: Add side band flow
 control support



On 10/10/2023 3:32 PM, Subash Abhinov Kasiviswanathan (KS) wrote:
> 
> 
> On 10/10/2023 12:21 PM, Jakub Kicinski wrote:
>> On Tue, 10 Oct 2023 09:23:12 -0600 Subash Abhinov Kasiviswanathan (KS)
>> wrote:
>>>
>>> I was wondering if it would be acceptable to add a user accessible
>>> interface in core networking to stop_queue / wake_queue instead of the
>>> driver.
>>
>> Maybe not driver queue control but if there's no qdisc which allows
>> users to pause from user space, I think that would be a much easier
>> sale.
>>
>> That said the flow of the whole thing seems a bit complex.
>> Can't the driver somehow be notified by the device directly?
>> User space will suffer from all sort of wake up / scheduling
>> latencies, it'd be better if the whole sleep / wake thing was
>> handled in the kernel.
> 
> Our userspace module relies on various inputs from radio hardware and 
> has proprietary logic to determine when to transmit / stop sending 
> packets corresponding to a specific bearer. I agree that an in kernel 
> scheme might be faster than an userspace - kernel solution. However, I 
> believe that this latency impact could be reduced through schemes like 
> setting process priority, pinning applications in isolated cores etc.

After reviewing the qdisc set closer, it appears that my understanding 
was incorrect as tc-plug provides userspace controllable queuing. Thanks 
for the help and discussion!