Linux Virtualization - Mar 2023 - [RFC PATCH v2 2/4] virtio/vsock: remove all data from sk_buff

On Mon, Mar 06, 2023 at 06:31:22PM +0300, Arseniy Krasnov
wrote:
>
>
>On 06.03.2023 15:08, Stefano Garzarella wrote:
>> On Sun, Mar 05, 2023 at 11:07:37PM +0300, Arseniy Krasnov wrote:
>>> In case of SOCK_SEQPACKET all sk_buffs are used once - after read
some
>>> data from it, it will be removed, so user will never read rest of
the
>>> data. Thus we need to update credit parameters of the socket like
whole
>>> sk_buff is read - so call 'skb_pull()' for the whole
buffer.
>>>
>>> Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt
with sk_buff")
>>> Signed-off-by: Arseniy Krasnov <AVKrasnov at sberdevices.ru>
>>> ---
>>> net/vmw_vsock/virtio_transport_common.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Maybe we could avoid this patch if we directly use pkt_len as I
>> suggested in the previous patch.
>Hm, may be we can avoid calling 'skb_pull()' here if
'virtio_transport_dec_rx_pkt()'
>will use integer argument?
Yep, exactly!
>Just call 'virtio_transport_dec_rx_pkt(skb->len)'. skb
It depends on how we call virtio_transport_inc_rx_pkt(). If we use
hdr->len there I would use the same to avoid confusion. Plus that's the
value the other peer sent us, so definitely the right value to increase
fwd_cnt with. But if skb->len always reflects it, then that's fine.
>is never returned to queue to read it again, so i think may be there is no
sense for
>extra call 'skb_pull'?
Right!

Thanks,
Stefano