Hi Zhike,
On 10/26/2017 8:53 PM, 王志克 wrote:
Hi,
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.
Thanks,
Jianfeng
