Re: [RFC] virtio-net: share receive_*() and add_recvbuf_*() with virtio-vsock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2019/7/10 下午11:37, Stefano Garzarella wrote:
Hi,
as Jason suggested some months ago, I looked better at the virtio-net driver to
understand if we can reuse some parts also in the virtio-vsock driver, since we
have similar challenges (mergeable buffers, page allocation, small
packets, etc.).

Initially, I would add the skbuff in the virtio-vsock in order to re-use
receive_*() functions.


Yes, that will be a good step.


Then I would move receive_[small, big, mergeable]() and
add_recvbuf_[small, big, mergeable]() outside of virtio-net driver, in order to
call them also from virtio-vsock. I need to do some refactoring (e.g. leave the
XDP part on the virtio-net driver), but I think it is feasible.

The idea is to create a virtio-skb.[h,c] where put these functions and a new
object where stores some attributes needed (e.g. hdr_len ) and status (e.g.
some fields of struct receive_queue).


My understanding is we could be more ambitious here. Do you see any blocker for reusing virtio-net directly? It's better to reuse not only the functions but also the logic like NAPI to avoid re-inventing something buggy and duplicated.


This is an idea of virtio-skb.h that
I have in mind:
     struct virtskb;


What fields do you want to store in virtskb? It looks to be exist sk_buff is flexible enough to us?



     struct sk_buff *virtskb_receive_small(struct virtskb *vs, ...);
     struct sk_buff *virtskb_receive_big(struct virtskb *vs, ...);
     struct sk_buff *virtskb_receive_mergeable(struct virtskb *vs, ...);

     int virtskb_add_recvbuf_small(struct virtskb*vs, ...);
     int virtskb_add_recvbuf_big(struct virtskb *vs, ...);
     int virtskb_add_recvbuf_mergeable(struct virtskb *vs, ...);

For the Guest->Host path it should be easier, so maybe I can add a
"virtskb_send(struct virtskb *vs, struct sk_buff *skb)" with a part of the code
of xmit_skb().


I may miss something, but I don't see any thing that prevents us from using xmit_skb() directly.



Let me know if you have in mind better names or if I should put these function
in another place.

I would like to leave the control part completely separate, so, for example,
the two drivers will negotiate the features independently and they will call
the right virtskb_receive_*() function based on the negotiation.


If it's one the issue of negotiation, we can simply change the virtnet_probe() to deal with different devices.



I already started to work on it, but before to do more steps and send an RFC
patch, I would like to hear your opinion.
Do you think that makes sense?
Do you see any issue or a better solution?


I still think we need to seek a way of adding some codes on virtio-net.c directly if there's no huge different in the processing of TX/RX. That would save us a lot time.

Thanks



Thanks in advance,
Stefano
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization




[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux