On Mon, Jul 15, 2019 at 05:16:09PM +0800, Jason Wang wrote: > > > > > > > > > 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. > > > > > > > > > > > > > Yes, but my initial idea was to make it more parametric and not > > > > > > related to the > > > > > > virtio_net_hdr, so the 'hdr_len' could be a parameter and the > > > > > > 'num_buffers' should be handled by the caller. > > > > > > > > > > > > > > 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. > > > > > > After the reading of the buffers from the virtqueue I think the > > > > > > process > > > > > > is slightly different, because virtio-net will interface with the > > > > > > network > > > > > > stack, while virtio-vsock will interface with the vsock-core > > > > > > (socket). > > > > > > So the virtio-vsock implements the following: > > > > > > - control flow mechanism to avoid to loose packets, informing the > > > > > > peer > > > > > > about the amount of memory available in the receive queue using > > > > > > some > > > > > > fields in the virtio_vsock_hdr > > > > > > - de-multiplexing parsing the virtio_vsock_hdr and choosing the > > > > > > right > > > > > > socket depending on the port > > > > > > - socket state handling > > > > > > I think it's just a branch, for ethernet, go for networking stack. > > > otherwise > > > go for vsock core? > > > > > Yes, that should work. > > > > So, I should refactor the functions that can be called also from the vsock > > core, in order to remove "struct net_device *dev" parameter. > > Maybe creating some wrappers for the network stack. > > > > Otherwise I should create a fake net_device for vsock_core. > > > > What do you suggest? > > > I'm not quite sure I get the question. Can you just use the one that created > by virtio_net?
Sure, sorry but I missed that it is allocated in the virtnet_probe()! Thanks, Stefano
