Re: [PATCH PATCH net-next v4 8/8] tls: Enable batch async decryption in read_sock

On Mon, Mar 23, 2026, at 10:14 AM, Sabrina Dubroca wrote:
> 2026-03-17, 11:04:21 -0400, Chuck Lever wrote:
>> diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
>> index 5ae7e0c026e4437fe442c3a77b0a6d9623816ce1..bc500ba7ce81eb33763c37a8b73473c42dc66044 100644
>> --- a/net/tls/tls_sw.c
>> +++ b/net/tls/tls_sw.c

>> @@ -2373,25 +2387,61 @@ int tls_sw_read_sock(struct sock *sk, read_descriptor_t *desc,
>>  	decrypted = 0;
>>  	for (;;) {
>>  		struct tls_decrypt_arg darg;
>> +		int nr_async = 0;
>>  
>> -		/* Phase 1: Submit -- decrypt one record onto rx_list. */
>> +		/* Phase 1: Submit -- decrypt records onto rx_list. */
>>  		if (skb_queue_empty(&ctx->rx_list)) {
>> -			err = tls_rx_rec_wait(sk, NULL, true, released);
>> -			if (err <= 0)
>> +			while (nr_async < TLS_READ_SOCK_BATCH) {
>> +				if (nr_async == 0) {
>> +					err = tls_rx_rec_wait(sk, NULL,
>> +							      true,
>> +							      released);
>> +					if (err <= 0)
>> +						goto read_sock_end;
>> +				} else {
>> +					if (!tls_strp_msg_ready(ctx)) {
>> +						tls_strp_check_rcv_quiet(&ctx->strp);
>> +						if (!tls_strp_msg_ready(ctx))
>> +							break;
>
> This (and tls_rx_rec_wait) looks like tls_strp_check_rcv_quiet should
> return the value of msg_ready.
>
> This is also not very different from tls_rx_rec_wait(nonblock=true),
> why are you separating the nr_async>0 case and open-coding the core
> operations from tls_rx_rec_wait()?

tls_rx_rec_wait() is designed for the blocking first-record case
with full error/shutdown handling. The batch loop needs a light-
weight non-blocking poll with different semantics: "is another
record already available? If not, stop." Reusing tls_rx_rec_wait()
would require either adding more parameters to skip irrelevant
checks, or having the caller distinguish -EAGAIN (no record) from
real errors -- both of which would be more complex than the
current code.

My calculus was that the code duplication was a more readable
choice than building a single complicated helper that would
obfuscate the two flows.

-- 
Chuck Lever