[dpdk-dev] [PATCH v2] vhost: add support for dynamic vhost PMD creation

Yuanhan Liu yuanhan.liu at linux.intel.com
Thu May 26 09:58:56 CEST 2016


On Wed, May 25, 2016 at 01:54:41PM +0200, Thomas Monjalon wrote:
> > OTOH, let's assume there is a switch that supports quite many such
> > vdevs, as well as the ability to add a new device dynamically by
> > corresponding API. And assume there is just one external interface
> > from the switch to add a dynamical device (say, "ovs-vsctl add-port"),
> > you then also need build some codes to invoke the right API, as well
> > as constructing the right parameters, like what you said below.
> > 
> > This let me think of the vhost dequeue/enqueue API. Basically speaking,
> > it has the same functionality the rte_eth_rx/tx_burst has, but just
> > different API name and different parameters. This results to OVS has
> > to write different netdev_class, one for NIC, another one for vhost-user.
> > (actually, there is yet another one for vhost-cuse).
> > 
> > And now since we have vhost-pmd, we could just have one netdev_class
> > at OVS, saving their (and other application's) effort to build/maintain
> > similar codes.
> 
> Yes, it was a good improvement.

Yeah, kudos to Tetsuya.

> > Thus, I'm __just wondering__ could we add a generic interface to create
> > vdev dynamically for all such vdevs? I was thinking something like:
> > 
> > 	rte_create_vdev(type, char *options);
> 
> Actually, it has more sense to first create the device with an attach()
> function and the configure it with devargs.
> So neither attaching nor configuring are specific to vdev.
> And devargs configuration can happen long after creating the device object.
> 
> I suggest to reject this patch and continue the EAL rework initiated
> by David.

I'm okay with that: I think it's better to use current interface
instead of adding a new one that will be refactored soon.

	--yliu


More information about the dev mailing list