[dpdk-users] VIRTIO for containers
jianfeng.tan at intel.com
Fri Oct 27 03:58:33 CEST 2017
On 10/26/2017 8:53 PM, 王志克 wrote:
> Thanks for reply.
> 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?).
> [Wang Zhike] Then in this case, another kthread like ksoftirq will be
> kicked, right?
> In my understanding, the advantage is that the rx performance can be
> even improvement, while disadvantage is that more cpu resource is used
> and another queue is needed. If that can be done in a smart way, like
> system has idle CPUs, we can use this way, else fall back to only use
> one kernel thread. Just my 2 cents.
Yes, make sense. We need a smart mechanism to decide if it is handled in
vhost kthread or ksoftirqd kthread. And also, we could even avoid
forking a vhost kthread, to avoid too many context switches.
More information about the users