On Fri, 17 Mar 2017 00:11:10 +0000 "Wiles, Keith" <keith.wi...@intel.com> wrote:
> > On Mar 17, 2017, at 7:41 AM, Vincent JARDIN <vincent.jar...@6wind.com> > > wrote: > > > > Let's be back to 2014 with Qemu's thoughts on it, > > +Stefan > > https://lists.linuxfoundation.org/pipermail/virtualization/2014-June/026767.html > > > > and > > +Markus > > https://lists.linuxfoundation.org/pipermail/virtualization/2014-June/026713.html > > > >> 6. Device models belong into QEMU > >> > >> Say you build an actual interface on top of ivshmem. Then ivshmem in > >> QEMU together with the supporting host code outside QEMU (see 3.) and > >> the lower layer of the code using it in guests (kernel + user space) > >> provide something that to me very much looks like a device model. > >> > >> Device models belong into QEMU. It's what QEMU does. > > > > > > Le 17/03/2017 à 00:17, Stephen Hemminger a écrit : > >> On Wed, 15 Mar 2017 04:10:56 +0000 > >> "O'Driscoll, Tim" <tim.odrisc...@intel.com> wrote: > >> > >>> I've included a couple of specific comments inline below, and a general > >>> comment here. > >>> > >>> We have somebody proposing to add a new driver to DPDK. It's standalone > >>> and doesn't affect any of the core libraries. They're willing to maintain > >>> the driver and have included a patch to update the maintainers file. > >>> They've also included the relevant documentation changes. I haven't seen > >>> any negative comment on the patches themselves except for a request from > >>> John McNamara for an update to the Release Notes that was addressed in a > >>> later version. I think we should be welcoming this into DPDK rather than > >>> questioning/rejecting it. > >>> > >>> I'd suggest that this is a good topic for the next Tech Board meeting. > >> > >> This is a virtualization driver for supporting DPDK on platform that > >> provides an alternative > >> virtual network driver. I see no reason it shouldn't be part of DPDK. > >> Given the unstable > >> ABI for drivers, supporting out of tree DPDK drivers is difficult. The > >> DPDK should try > >> to be inclusive and support as many environments as possible. > >> > > > > On Qemu mailing list, back to 2014, I did push to build models of devices > > over ivshmem, like AVP, but folks did not want that we abuse of it. The > > Qemu community wants that we avoid unfocusing. So, by being too much > > inclusive, we abuse of the Qemu's capabilities. > > > > So, because of being "inclusive", we should allow any cases, it is not a > > proper way to make sure that virtio gets all the focuses it deserves. > > > > > > Why are we bring QEMU in to the picture it does not make a lot of sense to > me. Stephen stated it well above and I hope my comments were stating the same > conclusion. I do not see your real reasons for not allowing this driver into > DPDK, it seems like some other hidden agenda is at play here, but I am a > paranoid person :-) I am thinking of people already using Windriver systems. One can argue all you want that they should be using QEMU/KVM/Virtio or 6Wind Virtual Accelerator but it is not the role of DPDK to be used to influence customers architecture decisions.
