[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7f3ecbaf-7759-88ae-53d3-2cc5b1623aff@gmail.com>
Date: Thu, 12 Aug 2021 20:46:23 +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/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.
> IMO, TCP_REPAIR hijacking standard system calls was a design error,
> we should have added new system calls.
You are right that adding new system calls is a better approach. What do you
think about adding a new option in getsockopt approach?
Thanks,
Quang Minh.
Powered by blists - more mailing lists