[dpdk-users] VIRTIO for containers

[Tan, Jianfeng]

Hi,

> [Wang Zhike] I once saw you mentioned that something like mmap 
> solution may be used. Is it still on your roadmap? I am not sure 
> whether it is same as the “vhost tx zero copy”.
>
> Can I know the forecasted day that the optimization can be done? Some 
> Linux kernel upstream module would be updated, or DPDK module? Just 
> want to know which modules will be touched.
>

Yes, I was planning to do that. But found out it helps on user->kernel 
path; not so easy for kernel->user path. It’s not the same as “vhost tx 
zero copy” (there are some restrictions BTW). The packet mmap would 
share a bulk of memory with user and kernel space, so that we don’t need 
to copy (the effect is the same with “vhost tx zero copy”). As for the 
date, it still lack of detailed design and feasibility analysis.

> 1) Yes, we have done some initial tests internally, with testpmd as 
> the vswitch instead of OVS-DPDK; and we were comparing with KNI for 
> exceptional path.
>
> [Wang Zhike]Can you please kindly indicate how to configure for KNI 
> mode? I would like to also compare it.
>

Now KNI is a vdev now. You can refer to this link: 
http://dpdk.org/doc/guides/nics/kni.html


> 2) We also see similar asymmetric result. For user->kernel path, it 
> not only copies data from mbuf to skb, but also might go above to tcp 
> stack (you can check using perf).
>
> [Wang Zhike] Yes, indeed. User->kernel path, tcp/ip related work is 
> done by vhost thread, while kernel to userthread, tcp/ip related work 
> is done by the app (my case netperf) in syscall.
>
>

To put tcp/ip rx into app thread, actually, might avoid that with a 
little change on tap driver. Currently, we use 
netif_rx/netif_receive_skb() to rx in tap, which could result in going 
up to the tcp/ip stack in the vhost kthread. Instead, we could backlog 
the packets into other cpu (application thread's cpu?).

Thanks,
Jianfeng