[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <bd1bbdb7-8fc2-4569-8eac-157caded5731@rbox.co>
Date: Wed, 30 Apr 2025 11:13:50 +0200
From: Michal Luczaj <mhal@...x.co>
To: Stefano Garzarella <sgarzare@...hat.com>
Cc: Luigi Leonardi <leonardi@...hat.com>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Simon Horman <horms@...nel.org>, "Michael S. Tsirkin" <mst@...hat.com>,
Jason Wang <jasowang@...hat.com>, Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
Eugenio Pérez <eperezma@...hat.com>,
Stefan Hajnoczi <stefanha@...hat.com>, virtualization@...ts.linux.dev,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH net-next v2 1/3] vsock: Linger on unsent data
On 4/28/25 15:56, Stefano Garzarella wrote:
> On Thu, Apr 24, 2025 at 01:24:59PM +0200, Michal Luczaj wrote:
>> On 4/24/25 10:36, Stefano Garzarella wrote:
>>> On Thu, 24 Apr 2025 at 09:53, Michal Luczaj <mhal@...x.co> wrote:
>>>> On 4/24/25 09:28, Stefano Garzarella wrote:
>
> [...]
>
>>>> You're right, it was me who was confused. VMCI and Hyper-V have their own
>>>> vsock_transport::release callbacks that do not call
>>>> virtio_transport_wait_close().
>>>>
>>>> So VMCI and Hyper-V never lingered anyway?
>>>
>>> I think so.
>>>
>>> Indeed I was happy with v1, since I think this should be supported by
>>> the vsock core and should not depend on the transport.
>>> But we can do also later.
>>
>> OK, for now let me fix this nonsense in comment and commit message.
>
> Thanks!
>
>>
>> But I'll wait for your opinion on [1] (drop, squash, change order of
>> patches?) before posting v3.
>
> I'm fine with a second patch to fix the indentation and the order looks
> fine.
>
> BTW I'm thinking if it makes sense to go back on moving the lingering in
> the core. I mean, if `unsent_bytes` is implemented, support linger, if
> not, don't support it, like now.
>
> That said, this should be implemented in another patch (or eventually
> another series if you prefer), so my idea is the following split:
> - use unsent_bytes() just in virtio
> - move linger support in af_vsock.c (depending on transports
> implementing unsent_bytes())
> - implement unsent_bytes() in other transports (in the future)
>
> WDYT?
Sure, makes sense. Even though I'm not certain I understand "use
unsent_bytes() just in virtio" part. Anyway, we can carry the discussion to
v3:
https://lore.kernel.org/netdev/20250430-vsock-linger-v3-0-ddbe73b53457@rbox.co/
Note that I took the liberty to assume unsent_bytes() is always there for
loopback/virtio transports. Check for NULL is introduced when the code is
moved to core. By the end of the series it changes nothing, but I hope it's
a tiny bit more sensible.
Thanks,
Michal
Powered by blists - more mailing lists