> 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
