[dpdk-dev] [PATCH] ethdev: fix wrong memset

Yuanhan Liu yuanhan.liu at linux.intel.com
Sat Jan 28 14:14:03 CET 2017

On Wed, Jan 25, 2017 at 12:16:58PM +0100, Thomas Monjalon wrote:
> > As I understand, the main problem is that  rte_eth_devices[] is local,
> > while rte_eth_dev_data points to the shared memory array.
> > And rte_eth_dev_allocate() assumes that if rte_eth_devices[x] is free,
> > then rte_eth_dev_data[port_id] is also free.
> > Which is wrong in case when primary/secondary processes have different devices attached.
> > Another problem is that inside rte_ethdev.c we manipulate rte_eth_dev_data[]
> > contents without grabbing any lock.
> Yes there are a lot of problems with the multiproc mode because it has
> been implemented as a hack.

Oh, right, "hacky" is the word I intended to say in my last email.

> We are fixing some cases without figuring the whole picture.


> I'll apply the patch from Remy which fixes a case where process creates

I would ask you not to apply that. IMO, his patch may have "fixed" a crash
he saw, but it doesn't looks like to me it really fixes anything: the driver 
may reference rte_eth_data belongs to another driver -- things can't be
right afterwards.

> vdev (local data) and, hopefully, primary does no hotplug of PCI dev.
> I'll restart this discussion with a bigger picture of what multiproc is,
> and what are the issues.

Great! And I'm keen to know how the multiproc is actually used in real
life (and why they don't use multiple thread). Most importantly, does
people really care about it? (I fixed few virtio multiproc issues that
I know there are some people/companies using it, and I want to know if
there are more).

OTOH, an initial idea comes to my mind now is, make the port_id a global
id among primary and secondary process:

- same device will get same port id (my patch acertains that)
- different device will get different port id


More information about the dev mailing list