netdev - Re: [PATCH bpf-next v2 01/10] net: introduce preferred busy-polling

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 16 Nov 2020 17:19:17 +0100
From:   Björn Töpel <bjorn.topel@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        Björn Töpel <bjorn.topel@...il.com>
Cc:     netdev@...r.kernel.org, bpf@...r.kernel.org,
        magnus.karlsson@...el.com, ast@...nel.org, daniel@...earbox.net,
        maciej.fijalkowski@...el.com, sridhar.samudrala@...el.com,
        jesse.brandeburg@...el.com, qi.z.zhang@...el.com,
        edumazet@...gle.com, jonathan.lemon@...il.com, maximmi@...dia.com
Subject: Re: [PATCH bpf-next v2 01/10] net: introduce preferred busy-polling

On 2020-11-16 17:04, Jakub Kicinski wrote:
> On Mon, 16 Nov 2020 12:04:07 +0100 Björn Töpel wrote:
>> @@ -6771,6 +6806,19 @@ static int napi_poll(struct napi_struct *n, struct list_head *repoll)
>>   	if (likely(work < weight))
>>   		goto out_unlock;
>>   
>> +	/* The NAPI context has more processing work, but busy-polling
>> +	 * is preferred. Exit early.
>> +	 */
>> +	if (napi_prefer_busy_poll(n)) {
>> +		if (napi_complete_done(n, work)) {
>> +			/* If timeout is not set, we need to make sure
>> +			 * that the NAPI is re-scheduled.
>> +			 */
>> +			napi_schedule(n);
>> +		}
>> +		goto out_unlock;
>> +	}
> 
> Why is this before the disabled check?
>

This path is when the budget was exceeded (more work to be done). If the
prefer flag is set, the napi loop is exited prematurely. We check the
return value for napi_complete_done, to make sure that there is actually
a TO value set.

Uhm, maybe I not following what you mean by the "disabled check".


Björn


>>   	/* Drivers must not modify the NAPI state if they
>>   	 * consume the entire weight.  In such cases this code
>>   	 * still "owns" the NAPI instance and therefore can