[PATCH 3/3] nvme-tcp: fix I/O stalls on congested sockets

Kamaljit Singh Kamaljit.Singh1 at wdc.com
Tue May 27 18:43:45 PDT 2025


Hi Sagi,

>On 27/05/2025 2:49, Sagi Grimberg wrote:
>>>
>>> We still need to hunt these down. I'm still puzzled why adding the
>>> WAKE_SENDER
>>> flag was able to make this issue disappear? I'll have another look at
>>> this patch.
>>>
>>> For now, I think we can go with this patchset, and then incrementally
>>> fix the remains.
>>
>> Kamaljit, can you check the following patch on top of the patchset
>> from Hannes that
>> gets a reproduction?
>>
>> --
>> diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
>> index 835e29014841..2f5f2fcfb078 100644
>> --- a/drivers/nvme/host/tcp.c
>> +++ b/drivers/nvme/host/tcp.c
>> @@ -1075,7 +1075,7 @@ static void nvme_tcp_write_space(struct sock *sk)
>>
>>         read_lock_bh(&sk->sk_callback_lock);
>>         queue = sk->sk_user_data;
>> -       if (likely(queue && sk_stream_is_writeable(sk))) {
>> +      if (likely(queue)) {
>>                 clear_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
>>                 queue_work_on(queue->io_cpu, nvme_tcp_wq,
>> &queue->io_work);
>>         }
>> --
>>
>> This think this may be preventing the scheduling of io_work. But now
>> that io_work is
>> also ceasing based on sk_stream_is_writeable, we should probably still
>> schedule it.
>
>Kamaljit? Any info on this?

Sorry for the delayed reply. We've been hitting one issue after another,
hence the delays. Hoping that by tomorrow I should have clean results with
a clear a-b comparison of only the changes you suggested.

Thanks,
Kamaljit


More information about the Linux-nvme mailing list