Hi Xie, (2014/11/14 9:22), Xie, Huawei wrote: >> I think so. I guess we need to consider 2 types of restarting. One is >> virtio-net driver restarting, the other is vhost-user backend >> restarting. But, so far, it's nice to start to think about virtio-net >> driver restarting first. Probably we need to implement a way to let >> vhost-user backend know virtio-net driver is restarted. I am not sure >> what is good way to let vhost-user backend know it. But how about >> followings RFC? > I checked your code today, and didn't find the logic to deal with virtio > reconfiguration. Yes. I guess the first implementation of librte_vhost may just replace vhost-example function. Probably vhost-example doesn't think about restarting. Because of this, I haven't implemented.
> My thought without new message support: When vhost-user receives > another configuration message since last time it is ready for > processing, then we could release it from data core, and process the > next reconfiguration message, and then re-add it to data core when it > is ready again(check new kick message as before). The candidate > message is set_mem_table. It is ok we keep the device on data core > until we receive the new reconfiguration message. Just waste vhost > some cycles checking the avail idx. For example, let's assume DPDK app1 is started on guest with virtio-net device port. If DPDK app1 on guest is stopped, and other DPDK app2 on guest is started without virtio-net device port. Hugepages DPDK app1 used will be used by DPDK app2. It means the memory accessed by vhost-user backend might be changed by DPDK app2. And vhost-user backend will be crashed. So I guess we need some kinds of reset message. Thanks, Tetsuya
