From: Jakub Kicinski <kuba@kernel.org>
To: davem@davemloft.net, pabeni@redhat.com
Cc: netdev@vger.kernel.org, borisp@nvidia.com,
john.fastabend@gmail.com, daniel@iogearbox.net,
vfedorenko@novek.ru, Jakub Kicinski <kuba@kernel.org>
Subject: [PATCH net-next 07/11] tls: rx: don't track the async count
Date: Fri, 8 Apr 2022 11:31:30 -0700 [thread overview]
Message-ID: <20220408183134.1054551-8-kuba@kernel.org> (raw)
In-Reply-To: <20220408183134.1054551-1-kuba@kernel.org>
We track both if the last record was handled by async crypto
and how many records were async. This is not necessary. We
implicitly assume once crypto goes async it will stay that
way, otherwise we'd reorder records. So just track if we're
in async mode, the exact number of records is not necessary.
This change also forces us into "async" mode more consistently
in case crypto ever decided to interleave async and sync.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
net/tls/tls_sw.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 6f17f599a6d4..183e5ec292a8 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -1751,13 +1751,13 @@ int tls_sw_recvmsg(struct sock *sk,
struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
struct tls_prot_info *prot = &tls_ctx->prot_info;
struct sk_psock *psock;
- int num_async, pending;
unsigned char control = 0;
ssize_t decrypted = 0;
struct strp_msg *rxm;
struct tls_msg *tlm;
struct sk_buff *skb;
ssize_t copied = 0;
+ bool async = false;
int target, err = 0;
long timeo;
bool is_kvec = iov_iter_is_kvec(&msg->msg_iter);
@@ -1789,12 +1789,10 @@ int tls_sw_recvmsg(struct sock *sk,
timeo = sock_rcvtimeo(sk, flags & MSG_DONTWAIT);
decrypted = 0;
- num_async = 0;
while (len && (decrypted + copied < target || ctx->recv_pkt)) {
struct tls_decrypt_arg darg = {};
bool retain_skb = false;
int to_decrypt, chunk;
- bool async;
skb = tls_wait_data(sk, psock, flags & MSG_DONTWAIT, timeo, &err);
if (!skb) {
@@ -1834,10 +1832,8 @@ int tls_sw_recvmsg(struct sock *sk,
goto recv_end;
}
- if (err == -EINPROGRESS) {
+ if (err == -EINPROGRESS)
async = true;
- num_async++;
- }
/* If the type of records being processed is not known yet,
* set it to record type just dequeued. If it is already known,
@@ -1911,7 +1907,9 @@ int tls_sw_recvmsg(struct sock *sk,
}
recv_end:
- if (num_async) {
+ if (async) {
+ int pending;
+
/* Wait for all previously submitted records to be decrypted */
spin_lock_bh(&ctx->decrypt_compl_lock);
reinit_completion(&ctx->async_wait.completion);
--
2.34.1
next prev parent reply other threads:[~2022-04-08 18:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-08 18:31 [PATCH net-next 00/11] tls: rx: random refactoring part 2 Jakub Kicinski
2022-04-08 18:31 ` [PATCH net-next 01/11] tls: rx: drop unnecessary arguments from tls_setup_from_iter() Jakub Kicinski
2022-04-08 18:31 ` [PATCH net-next 02/11] tls: rx: don't report text length from the bowels of decrypt Jakub Kicinski
2022-04-08 18:31 ` [PATCH net-next 03/11] tls: rx: wrap decryption arguments in a structure Jakub Kicinski
2022-04-08 18:31 ` [PATCH net-next 04/11] tls: rx: simplify async wait Jakub Kicinski
2022-04-08 18:31 ` [PATCH net-next 05/11] tls: rx: factor out writing ContentType to cmsg Jakub Kicinski
2022-04-08 18:31 ` [PATCH net-next 06/11] tls: rx: don't handle async in tls_sw_advance_skb() Jakub Kicinski
2022-04-08 18:31 ` Jakub Kicinski [this message]
2022-04-08 18:31 ` [PATCH net-next 08/11] tls: rx: pull most of zc check out of the loop Jakub Kicinski
2022-04-08 18:31 ` [PATCH net-next 09/11] tls: rx: inline consuming the skb at the end " Jakub Kicinski
2022-04-08 18:31 ` [PATCH net-next 10/11] tls: rx: clear ctx->recv_pkt earlier Jakub Kicinski
2022-05-18 12:43 ` Artem Savkov
2022-04-08 18:31 ` [PATCH net-next 11/11] tls: rx: jump out for cases which need to leave skb on list Jakub Kicinski
2022-04-08 19:03 ` [PATCH net-next 00/11] tls: rx: random refactoring part 2 John Fastabend
2022-04-10 16:40 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220408183134.1054551-8-kuba@kernel.org \
--to=kuba@kernel.org \
--cc=borisp@nvidia.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=john.fastabend@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=vfedorenko@novek.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).