> On Mar 17, 2017, at 8:31 AM, Vincent JARDIN <vincent.jar...@6wind.com> wrote:
> 
> Le 17/03/2017 à 01:11, Wiles, Keith a écrit :
>> it seems like some other hidden agenda is at play here, but I am a paranoid 
>> person :-)
> 
> Keith, please stop such invalid argument! It is non sense.
> 
> We need to understand the benefits of diverging from virtio since here it is 
> about creating new device models for Qemu while bypassing qemu using ivshmem. 
> I do not care whether it is memnic, AVP, xyz. But I do care about Qemu's and 
> virtio's performances along with avoiding to get too many NIC models while 1 
> model can be used to have uniform IOs.

Vincent, the problem is just because you state my argument is invalid does not 
make it so. The problem is we would have to remove a number of drivers in DPDK 
as they provide the same functionality with your logic. To the extreme we would 
have to start removing drivers that did not perform well against another 
PMD/hardware. You have requested that AVP must be faster to even be consider 
into DPDK by requesting performance data.

Now you are stating the virtio is the only way to provide this type of 
transport, which is not the case. Using virtio or some other method is up to 
the developers of the product to use as it may be filling a solution which is 
not just speed or security or something else.

Restricting what PMDs go into DPDK is going to seem like a we (DPDK) do not 
want anything but our own code or ideas of what is best. PMDs are many and all 
of them handle Ethernet packets, should we start restricting PMDs to only one 
Ethernet supported device, NO.

Regardless of what the transport layer is ivshmem, virtio sharemem, ethernet, a 
serial line at 9600 baud or two squirrels transferring nuts it just does not 
make sense to restrict a transport type like ivshmem (that AVP is using) over 
any other transport type for DPDK and the community.

> 
> 

Regards,
Keith

Reply via email to