linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: io_uring_enter() with opcode IORING_OP_RECV ignores MSG_WAITALL in msg_flags
       [not found] <BYAPR15MB260078EC747F0F0183D1BB1BFA189@BYAPR15MB2600.namprd15.prod.outlook.com>
@ 2022-03-23 12:19 ` Jens Axboe
  2022-03-23 19:40   ` Pavel Begunkov
  0 siblings, 1 reply; 3+ messages in thread
From: Jens Axboe @ 2022-03-23 12:19 UTC (permalink / raw)
  To: Constantine Gavrilov, linux-kernel; +Cc: io-uring

On 3/23/22 4:31 AM, Constantine Gavrilov wrote:
> I get partial receives on TCP socket, even though I specify
> MSG_WAITALL with IORING_OP_RECV opcode. Looking at tcpdump in
> wireshark, I see entire reassambled packet (+4k), so it is not a
> disconnect. The MTU is smaller than 4k.
> 
> From the mailing list history, looks like this was discussed before
> and it seems the fix was supposed to be in. Can someone clarify the
> expected behavior?
> 
> I do not think rsvmsg() has this issue.

Do you have a test case? I added the io-uring list, that's the
appropriate forum for this kind of discussion.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: io_uring_enter() with opcode IORING_OP_RECV ignores MSG_WAITALL in msg_flags
  2022-03-23 12:19 ` io_uring_enter() with opcode IORING_OP_RECV ignores MSG_WAITALL in msg_flags Jens Axboe
@ 2022-03-23 19:40   ` Pavel Begunkov
  0 siblings, 0 replies; 3+ messages in thread
From: Pavel Begunkov @ 2022-03-23 19:40 UTC (permalink / raw)
  To: Jens Axboe, Constantine Gavrilov, linux-kernel; +Cc: io-uring

On 3/23/22 12:19, Jens Axboe wrote:
> On 3/23/22 4:31 AM, Constantine Gavrilov wrote:
>> I get partial receives on TCP socket, even though I specify
>> MSG_WAITALL with IORING_OP_RECV opcode. Looking at tcpdump in
>> wireshark, I see entire reassambled packet (+4k), so it is not a
>> disconnect. The MTU is smaller than 4k.
>>
>>  From the mailing list history, looks like this was discussed before
>> and it seems the fix was supposed to be in. Can someone clarify the
>> expected behavior?
>>
>> I do not think rsvmsg() has this issue.
> 
> Do you have a test case? I added the io-uring list, that's the
> appropriate forum for this kind of discussion.

MSG_WAITALL (since Linux 2.2)
        This flag requests that the operation block until the full
        request is satisfied.  However, the call may still return
        less data than requested if a signal is caught

My guess would be that it's either due to signals (including
task_works actively used by io_uring) or because of some
interoperability problem with NOWAIT.

-- 
Pavel Begunkov

^ permalink raw reply	[flat|nested] 3+ messages in thread

* io_uring_enter() with opcode IORING_OP_RECV ignores MSG_WAITALL in msg_flags
@ 2022-03-23 12:11 Constantine Gavrilov
  0 siblings, 0 replies; 3+ messages in thread
From: Constantine Gavrilov @ 2022-03-23 12:11 UTC (permalink / raw)
  To: linux-kernel

I get partial receives on TCP socket, even though I specify MSG_WAITALL 
with IORING_OP_RECV opcode. Looking at tcpdump in wireshark, I see 
entire reassambled packet (+4k), so it is not a disconnect. The MTU is 
smaller than 4k.

From
 the mailing list history, looks like this was discussed before and it 
seems the fix was supposed to be in. Can someone clarify the expected 
behavior?

I do not think rsvmsg() has this issue.

-- 
----------------------------------------
Constantine Gavrilov
Storage Architect
Master Inventor
Tel-Aviv IBM Storage Lab
1 Azrieli Center, Tel-Aviv
----------------------------------------

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-03-23 19:41 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <BYAPR15MB260078EC747F0F0183D1BB1BFA189@BYAPR15MB2600.namprd15.prod.outlook.com>
2022-03-23 12:19 ` io_uring_enter() with opcode IORING_OP_RECV ignores MSG_WAITALL in msg_flags Jens Axboe
2022-03-23 19:40   ` Pavel Begunkov
2022-03-23 12:11 Constantine Gavrilov

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).