On 2015/11/20 11:35, Tetsuya Mukawa wrote: > On 2015/11/20 11:00, Xie, Huawei wrote: >> On 11/20/2015 2:16 AM, Rich Lane wrote: >>> What's the reason for using qemu as a middleman? Couldn't the new PMD >>> itself open /dev/vhost-net or the vhost-user socket and send the commands >>> to set up virtqueues? That was the approach taken by Jianfeng's earlier RFC. >> Rich: >> Our initial POC also has a device simulation layer, but it is linked >> with the DPDK driver as a library. >> As i created that device simulation based on lkvm, and it takes too much >> effort to rewrite it from scratch, so we decide to release a simple >> version without device simulation first. >> Without device simulation, The PMD is pretty simple, standalone, no >> dependency to qtest process. >> With device simulation, we could easily implement other virtio device in >> DPDK easily, like virtio-crypt. > Hi Rich and Xie, > > Probably, how to prepare virtio-net device is the difference between > Jianfeng's RFC and our RFC. > The reason why I choose this approach is below. > > 1. Ease of maintenance > If we have our virtio-net device, we need to spend time to maintain it. > And QEMU virtio-net code is more tested by more virtio-net drivers and > more users. As a result, it should have less bugs. > Also, If we uses QEMU virtio-net code, we only need to maintain QTest > related implementation. > Anyway, QTest is very stable. > Probably we have bugs first, but later, we don't need to maintain it so > much. > > 2. Extendability > The virtio-net and vhost specification will be extended in the future. > If we have own implementation, we need to maintain more codes. > > >> Maybe anyway we provide the simple implementation option, for customers >> who don't like the extra complexity to launch a secondary process in >> their container. >> [...] >> >> > For example, for the user who is OK to invoke 2 processes in same > container, just prepare shell script that invokes QTest process and > vhost-user backend process will be enough. > > For the users who doesn't want to invoke 2 processes in one container, > anyway they use some kind of orchestration tool, so invoking one more > process/container is not difficult. > > I guess the invoking and connecting multiple processes over containers > may not be something special for container users. > (like deploying load balancer, web server and DB) > > Tetsuya
But yes, it may be nice to have option for the users who only needs limited features. Actually, I am not container users, so not sure which is preferred. If we have the option, I guess we need to choose very limited features to be easy to maintain. Thanks, Tetsuya
