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?
Thanks
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
