From: Hannes Reinecke <hare@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Sagi Grimberg <sagi@grimberg.me>, Keith Busch <kbusch@kernel.org>,
linux-nvme@lists.infradead.org, Hannes Reinecke <hare@kernel.org>
Subject: [PATCH] nvme-tcp: strict pdu pacing to avoid send stalls on TLS
Date: Wed, 17 Apr 2024 17:39:23 +0200 [thread overview]
Message-ID: <20240417153923.100342-1-hare@kernel.org> (raw)
TLS requires a strict pdu pacing via MSG_EOR to signal the end
of a record and subsequent encryption. If we do not set MSG_EOR
at the end of a sequence the record won't be closed, encryption
doesn't start, and we end up with a send stall as the message
will never be passed on to the TCP layer.
So do not check for the queue status when figuring out whether
MSG_MORE should be set but rather make it dependent on the current
command only.
Signed-off-by: Hannes Reinecke <hare@kernel.org>
---
drivers/nvme/host/tcp.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
index 2b821cbbdf1f..b460ebf72a1a 100644
--- a/drivers/nvme/host/tcp.c
+++ b/drivers/nvme/host/tcp.c
@@ -1049,7 +1049,7 @@ static int nvme_tcp_try_send_data(struct nvme_tcp_request *req)
int req_data_sent = req->data_sent;
int ret;
- if (last && !queue->data_digest && !nvme_tcp_queue_more(queue))
+ if (last && !queue->data_digest)
msg.msg_flags |= MSG_EOR;
else
msg.msg_flags |= MSG_MORE;
@@ -1105,7 +1105,7 @@ static int nvme_tcp_try_send_cmd_pdu(struct nvme_tcp_request *req)
int len = sizeof(*pdu) + hdgst - req->offset;
int ret;
- if (inline_data || nvme_tcp_queue_more(queue))
+ if (inline_data)
msg.msg_flags |= MSG_MORE;
else
msg.msg_flags |= MSG_EOR;
@@ -1175,17 +1175,12 @@ static int nvme_tcp_try_send_ddgst(struct nvme_tcp_request *req)
size_t offset = req->offset;
u32 h2cdata_left = req->h2cdata_left;
int ret;
- struct msghdr msg = { .msg_flags = MSG_DONTWAIT };
+ struct msghdr msg = { .msg_flags = MSG_DONTWAIT | MSG_EOR };
struct kvec iov = {
.iov_base = (u8 *)&req->ddgst + req->offset,
.iov_len = NVME_TCP_DIGEST_LENGTH - req->offset
};
- if (nvme_tcp_queue_more(queue))
- msg.msg_flags |= MSG_MORE;
- else
- msg.msg_flags |= MSG_EOR;
-
ret = kernel_sendmsg(queue->sock, &msg, &iov, 1, iov.iov_len);
if (unlikely(ret <= 0))
return ret;
--
2.35.3
next reply other threads:[~2024-04-17 15:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 15:39 Hannes Reinecke [this message]
2024-04-18 8:01 ` [PATCH] nvme-tcp: strict pdu pacing to avoid send stalls on TLS Sagi Grimberg
2024-04-18 9:05 ` Hannes Reinecke
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=20240417153923.100342-1-hare@kernel.org \
--to=hare@kernel.org \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).