On Tue, 1 Sep 2009 14:58:19 +0800
"Xin, Xiaohui" wrote:
> [RFC] Virtual Machine Device Queues (VMDq) support on KVM
>
> Network adapter with VMDq technology presents multiple pairs of tx/rx queues,
> and renders network L2 sorting mechanism based on MAC addresses and VLAN tags
> fo
>It may be possible to make vmdq appear like an sr-iov capable device
>from userspace. sr-iov provides the userspace interfaces to allocate
>interfaces and assign mac addresses. To make it useful, you would have
>to handle tx multiplexing in the driver but that would be much easier to
>consu
[RFC] Virtual Machine Device Queues (VMDq) support on KVM
Network adapter with VMDq technology presents multiple pairs of tx/rx queues,
and renders network L2 sorting mechanism based on MAC addresses and VLAN tags
for each tx/rx queue pair. Here we present a generic framework, in whi
> One way to share the effort is to make vmdq queues available as normal
kernel interfaces. It would take quite a bit of work, but the end
result is that no other components need to be change, and it makes vmdq
useful outside kvm. It also greatly reduces the amount of integration
work needed
>I don't think we should do that with the tun/tap driver. By design, tun/tap is
>a way to interact >with the
>networking stack as if coming from a device. The only way this connects to an
>external >adapter is through
>a bridge or through IP routing, which means that it does not correspond to a
Hi, Michael
That's a great job. We are now working on support VMDq on KVM, and since the
VMDq hardware presents L2 sorting based on MAC addresses and VLAN tags, our
target is to implement a zero copy solution using VMDq. We stared from the
virtio-net architecture. What we want to proposal is to
>* Code is easier to review than bullet points.
Yes. We'd send the code soon.
>* Direct I/O has to be safe when page is shared by multiple threads,
> and has to be non-blocking since network I/O can take indeterminately
> long (think big queue's, tunneling, ...)
In the situation, one que
