From: Sagi Grimberg <sagi@grimberg.me>
To: Hannes Reinecke <hare@kernel.org>, Christoph Hellwig <hch@lst.de>
Cc: Keith Busch <kbusch@kernel.org>, linux-nvme@lists.infradead.org
Subject: Re: [PATCH 1/8] nvme-tcp: switch TX deadline to microseconds and make it configurable
Date: Thu, 18 Jul 2024 00:03:22 +0300 [thread overview]
Message-ID: <f73ab2c4-e273-4da8-9a6e-462b3d2b8ac9@grimberg.me> (raw)
In-Reply-To: <20240716073616.84417-2-hare@kernel.org>
On 16/07/2024 10:36, Hannes Reinecke wrote:
> The current TX deadline for the workqueue is pretty much arbitrary,
> and jiffies is not the best choice for sub-microseconds granularity.
> So make the deadline configurable via a config option and switch to
> ktime instead of jiffies.
I thought we agreed on bytes based limits. Did you try to look how does
that behave?
>
> Signed-off-by: Hannes Reinecke <hare@kernel.org>
> ---
> drivers/nvme/host/tcp.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
> index 0873b3949355..3cf9a9abb0e0 100644
> --- a/drivers/nvme/host/tcp.c
> +++ b/drivers/nvme/host/tcp.c
> @@ -44,6 +44,10 @@ static bool wq_unbound;
> module_param(wq_unbound, bool, 0644);
> MODULE_PARM_DESC(wq_unbound, "Use unbound workqueue for nvme-tcp IO context (default false)");
>
> +static int deadline = 1000;
> +module_param(deadline, int, 0644);
> +MODULE_PARM_DESC(deadline, "RX/TX deadline in microseconds (default: 1000)");
> +
> /*
> * TLS handshake timeout
> */
> @@ -1278,7 +1282,8 @@ static void nvme_tcp_io_work(struct work_struct *w)
> {
> struct nvme_tcp_queue *queue =
> container_of(w, struct nvme_tcp_queue, io_work);
> - unsigned long deadline = jiffies + msecs_to_jiffies(1);
> + u64 start = ktime_to_us(ktime_get());
> + u64 tx_deadline = start + deadline;
>
> do {
> bool pending = false;
> @@ -1302,7 +1307,7 @@ static void nvme_tcp_io_work(struct work_struct *w)
> if (!pending || !queue->rd_enabled)
> return;
>
> - } while (!time_after(jiffies, deadline)); /* quota is exhausted */
> + } while (ktime_to_us(ktime_get()) < tx_deadline); /* quota is exhausted */
>
> queue_work_on(queue->io_cpu, nvme_tcp_wq, &queue->io_work);
> }
The rename to tx_deadline does not make sense in the context of this patch.
next prev parent reply other threads:[~2024-07-17 21:03 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-16 7:36 [PATCHv3 0/8] nvme-tcp: improve scalability Hannes Reinecke
2024-07-16 7:36 ` [PATCH 1/8] nvme-tcp: switch TX deadline to microseconds and make it configurable Hannes Reinecke
2024-07-17 21:03 ` Sagi Grimberg [this message]
2024-07-18 6:30 ` Hannes Reinecke
2024-07-16 7:36 ` [PATCH 2/8] nvme-tcp: io_work stall debugging Hannes Reinecke
2024-07-17 21:05 ` Sagi Grimberg
2024-07-16 7:36 ` [PATCH 3/8] nvme-tcp: re-init request list entries Hannes Reinecke
2024-07-17 21:23 ` Sagi Grimberg
2024-07-16 7:36 ` [PATCH 4/8] nvme-tcp: improve stall debugging Hannes Reinecke
2024-07-17 21:11 ` Sagi Grimberg
2024-07-16 7:36 ` [PATCH 5/8] nvme-tcp: debugfs entries for latency statistics Hannes Reinecke
2024-07-17 21:14 ` Sagi Grimberg
2024-07-16 7:36 ` [PATCH 6/8] nvme-tcp: reduce callback lock contention Hannes Reinecke
2024-07-17 21:19 ` Sagi Grimberg
2024-07-18 6:42 ` Hannes Reinecke
2024-07-21 11:46 ` Sagi Grimberg
2024-07-16 7:36 ` [PATCH 7/8] nvme-tcp: check for SOCK_NOSPACE before sending Hannes Reinecke
2024-07-17 21:19 ` Sagi Grimberg
2024-07-16 7:36 ` [PATCH 8/8] nvme-tcp: align I/O cpu with blk-mq mapping Hannes Reinecke
2024-07-17 21:34 ` Sagi Grimberg
2024-08-13 19:36 ` Sagi Grimberg
2024-07-17 21:01 ` [PATCHv3 0/8] nvme-tcp: improve scalability Sagi Grimberg
2024-07-18 6:20 ` Hannes Reinecke
2024-07-21 12:05 ` Sagi Grimberg
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=f73ab2c4-e273-4da8-9a6e-462b3d2b8ac9@grimberg.me \
--to=sagi@grimberg.me \
--cc=hare@kernel.org \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
/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