On Mon, Oct 19, 2015 at 10:32:50AM +0100, Loftus, Ciara wrote: > > On 2015/10/16 21:52, Bruce Richardson wrote: > > > On Mon, Aug 31, 2015 at 12:55:26PM +0900, Tetsuya Mukawa wrote: > > >> The patch introduces a new PMD. This PMD is implemented as thin > > wrapper > > >> of librte_vhost. It means librte_vhost is also needed to compile the PMD. > > >> The PMD can have 'iface' parameter like below to specify a path to > > connect > > >> to a virtio-net device. > > >> > > >> $ ./testpmd -c f -n 4 --vdev 'eth_vhost0,iface=/tmp/sock0' -- -i > > >> > > >> To connect above testpmd, here is qemu command example. > > >> > > >> $ qemu-system-x86_64 \ > > >> <snip> > > >> -chardev socket,id=chr0,path=/tmp/sock0 \ > > >> -netdev vhost-user,id=net0,chardev=chr0,vhostforce \ > > >> -device virtio-net-pci,netdev=net0 > > >> > > >> Signed-off-by: Tetsuya Mukawa <mukawa at igel.co.jp> > > > With this PMD in place, is there any need to keep the existing vhost > > > library > > > around as a separate entity? Can the existing library be > > subsumed/converted into > > > a standard PMD? > > > > > > /Bruce > > > > Hi Bruce, > > > > I concern about whether the PMD has all features of librte_vhost, > > because librte_vhost provides more features and freedom than ethdev API > > provides. > > In some cases, user needs to choose limited implementation without > > librte_vhost. > > I am going to eliminate such cases while implementing the PMD. > > But I don't have strong belief that we can remove librte_vhost now. > > > > So how about keeping current separation in next DPDK? > > I guess people will try to replace librte_vhost to vhost PMD, because > > apparently using ethdev APIs will be useful in many cases. > > And we will get feedbacks like "vhost PMD needs to support like this usage". > > (Or we will not have feedbacks, but it's also OK.) > > Then, we will be able to merge librte_vhost and vhost PMD. > > I agree with the above. One the concerns I had when reviewing the patch was > that the PMD removes some freedom that is available with the library. Eg. > Ability to implement the new_device and destroy_device callbacks. If using > the PMD you are constrained to the implementations of these in the PMD > driver, but if using librte_vhost, you can implement your own with whatever > functionality you like - a good example of this can be seen in the vhost > sample app. > On the other hand, the PMD is useful in that it removes a lot of complexity > for the user and may work for some more general use cases. So I would be in > favour of having both options available too. > > Ciara >
Thanks. However, just because the libraries are merged does not mean that you need be limited by PMD functionality. Many PMDs provide additional library-specific functions over and above their PMD capabilities. The bonded PMD is a good example here, as it has a whole set of extra functions to create and manipulate bonded devices - things that are obviously not part of the general ethdev API. Other vPMDs similarly include functions to allow them to be created on the fly too. regards, /Bruce