[dpdk-dev] [PATCH] ethdev: fix wrong memset
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