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

Remy Horton remy.horton at intel.com
Mon Jan 30 12:07:56 CET 2017

On 28/01/2017 13:14, Yuanhan Liu wrote:
>> 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.

I've self-NAK'd it as the code path it was aimed at no longer occurrs.

>> 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).

The use-cases I'm coming across are to allow the attaching/detaching of 
external agents mainly for information-reporting purposes, without 
having to leave hooks everywhere. In this case main advantage is the 
relative ease that processes can be hot-plugged in a way threads cannot. 
I suppose something more heavyweight might be a primary process as a 
host physical interconnect, with secondary processes being virtual 
machines - in this case these might be large semi-independent code-bases 
one does not want in the same process image.

To me the major down-side with DPDK's multiprocess model is how 
address-space layout randomisation can trip things up. I know parts of 
the code seems ASLR-safe, but I very much doubt all of it is.


More information about the dev mailing list