Re: [dpdk-dev] [RFC PATCH 0/2] Virtio-net PMD Extension to work on host.

[Tetsuya Mukawa <mukawa@igel.co.jp>]

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