[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3f861c1d-bd33-f074-8ef3-eede9bff73c1@gmail.com>
Date: Fri, 13 Aug 2021 18:08:28 +0700
From: Bui Quang Minh <minhquangbui99@...il.com>
To: Eric Dumazet <eric.dumazet@...il.com>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Cc: davem@...emloft.net, kuba@...nel.org, yoshfuji@...ux-ipv6.org,
dsahern@...nel.org, willemb@...gle.com, pabeni@...hat.com,
avagin@...il.com, alexander@...alicyn.com,
lesedorucalin01@...il.com
Subject: Re: [PATCH v2 1/2] udp: UDP socket send queue repair
On 8/12/2021 10:51 PM, Eric Dumazet wrote:
>
>
> On 8/12/21 3:46 PM, Bui Quang Minh wrote:
>>
>>
>> On 8/11/2021 11:14 PM, Eric Dumazet wrote:
>>>
>>>
>>> On 8/11/21 5:45 PM, Bui Quang Minh wrote:
>>>> In this patch, I implement UDP_REPAIR sockoption and a new path in
>>>> udp_recvmsg for dumping the corked packet in UDP socket's send queue.
>>>>
>>>> A userspace program can use recvmsg syscall to get the packet's data and
>>>> the msg_name information of the packet. Currently, other related
>>>> information in inet_cork that are set in cmsg are not dumped.
>>>>
>>>> While working on this, I was aware of Lese Doru Calin's patch and got some
>>>> ideas from it.
>>>
>>>
>>> What is the use case for this feature, adding a test in UDP fast path ?
>>
>> This feature is used to help CRIU to dump CORKed UDP packet in send queue. I'm sorry for being not aware of the performance perspective here.
>
> UDP is not reliable.
>
> I find a bit strange we add so many lines of code
> for a feature trying very hard to to drop _one_ packet.
>
> I think a much better changelog would be welcomed.
The reason we want to dump the packet in send queue is to make to state of the
application consistent. The scenario is that when an application sends UDP
packets via UDP_CORK socket or with MSG_MORE, CRIU comes and checkpoints the
application. If we drop the data in send queue, when application restores, it
sends some more data then turns off the cork and actually sends a packet. The
receiving side may get that packet but it's unusual that the first part of that
packet is missing because we drop it. So we try to solve this problem with some
help from the Linux kernel.
Thanks,
Quang Minh.
Powered by blists - more mailing lists