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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.