On 2016/06/06 16:21, Yuanhan Liu wrote: > On Mon, Jun 06, 2016 at 02:10:46PM +0900, Tetsuya Mukawa wrote: >> Hi Yuanhan, >> >> Sorry for late replying. > > Never mind. > >> >> On 2016/06/03 13:17, Yuanhan Liu wrote: >>> On Thu, Jun 02, 2016 at 06:30:18PM +0900, Tetsuya Mukawa wrote: >>>> Hi Yuanhan, >>>> >>>> On 2016/06/02 16:31, Yuanhan Liu wrote: >>>>> But still, I'd ask do we really need 2 virtio for container solutions? >>>> >>>> I appreciate your comments. >>> >>> No, I appreciate your effort for contributing to DPDK! vhost-pmd stuff >>> is just brilliant! >>> >>>> Let me have time to discuss it with our team. >>> >>> I'm wondering could we have one solution only. IMO, the drawback of >>> having two (quite different) solutions might outweighs the benefit >>> it takes. Say, it might just confuse user. >> >> I agree with this. >> If we have 2 solutions, it would confuse the DPDK users. >> >>> >>> OTOH, I'm wondering could you adapt to Jianfeng's solution? If not, >>> what's the missing parts, and could we fix it? I'm thinking having >>> one unified solution will keep ours energy/focus on one thing, making >>> it better and better! Having two just splits the energy; it also >>> introduces extra burden for maintaining. >> >> Of course, I adopt Jiangeng's solution basically. >> Actually, his solution is almost similar I tried to implement at first. >> >> I guess here is pros/cons of 2 solutions. >> >> [Jianfeng's solution] >> - Pros >> Don't need to invoke QEMU process. >> - Cons >> If virtio-net specification is changed, we need to implement it by >> ourselves. Also, LSC interrupt and control queue functions are not >> supported yet. > > Jianfeng have made and sent out the patch to enable ctrl queue and > multiple queue support.
Sorry, I haven't noticed that ctrl queue has been already enabled. > > For the LSC part, no much idea yet so far. But I'm assuming it will > not take too much effort, either. > >> I agree both functions may not be so important, and if we need it >> we can implement them, but we need to pay energy to implement them. >> >> [My solution] >> - Pros >> Basic principle of my implementation is not to reinvent the wheel. > > Yes, that's a good point. However, it's not that hard as we would have > thought in the first time: the tough part that dequeue/enqueue packets > from/to vring is actually offloaded to DPDK vhost-user. That means we > only need re-implement the control path of virtio-net device, plus the > vhost-user frontend. If you have a detailed look of your patchset as > well Jianfeng's, you might find that the two patchset are actually with > same code size. Yes, I know this. So far, the amount of code is almost same, but in the future we may need to implement more, if virtio-net specification is revised. > >> We can use a virtio-net device of QEMU implementation, it means we don't >> need to maintain virtio-net device by ourselves, and we can use all of >> functions supported by QEMU virtio-net device. >> - Cons >> Need to invoke QEMU process. > > Another thing is that it makes the usage a bit harder: look at the > long qemu cli options of your example usage. It also has some traps, > say, "--enable-kvm" is not allowed, which is a default option used > with QEMU. Probably a kind of shell script will help the users. > > And judging that we actually don't take too much effort to implement > a virtio device emulation, I'd prefer it slightly. I guess something > light weight and easier for use is more important here. This is very important point. If so, we don't need much effort when virtio-spec is changed. > > Actually, I have foreseen another benefit of adding virtio-user device > emulation: we now might be able to add a rte_vhost_dequeue/enqueue_burst() > unit test case. We simply can't do it before, since we depend on QEMU > for testing, which is not acceptable for a unit test case. Making it > be a unit test case would help us spotting any bad changes that would > introduce bugs easily and automatically. As you mentioned above, QEMU process is not related with dequeuing/enqueuing. So I guess we may have a testing for rte_vhost_dequeue/enqueue_burst() regardless of choice. >> Anyway, we can choose one of belows. >> 1. Take advantage of invoking less processes. >> 2. Take advantage of maintainability of virtio-net device. If container usage that DPDK assumes is to invoke hundreds containers in one host, we should take Jiangfeng's solution. Also, if implementing a new feature and maintaining Jiangfeng's virtio-net device are not so hard, we should take his solution. I guess this is the point we need to consider. What do you think? Thanks, Tetsuya >> >> Honestly, I'm OK if my solution is not merged. >> Thus, it should be decided to let DPDK better. >> >> What do you think? >> Which is better for DPDK? >> >> Thanks, >> Tetsuya >> >>> >>> --yliu >>>
