Re: [dpdk-dev] [PATCH v6 00/10] Register non-EAL threads as lcore

Hi David,
 

OVS and some other applications have been hacking into DPDK internals to
fake EAL threads and avoid performance penalty of only having non-EAL
threads.

This series proposes to add a new type of lcores and maps those threads
to such lcores.
non-EAL threads won't run the DPDK eal mainloop.
As a consequence, part of the EAL threads API cannot work.

Having new lcores appearing during the process lifetime is not expected
by some DPDK components. This is addressed by introducing init/uninit
callacks invoked when hotplugging of such lcore.

There is still some work/discussion:
- refuse new lcore role in incompatible EAL threads API (or document it
  only as those API were already incompatible?),
- think about deprecation notices for existing RTE_FOREACH_LCORE macros
  and consorts, it is probably worth discussing on how to iterate over
  lcores,

For the interested parties, I have a patch [1] against dpdk-latest OVS
branch that makes use of this series (this patch probably won't work with
v5, it will be rebased once dpdk side is ready).

1: https://patchwork.ozlabs.org/project/openvswitch/patch/20200626123017.28555-1-david.marchand@redhat.com/

Changes since v5:
- fixed windows build,

Changes since v4:
- added separate API to control mp feature activation,
- addressed Konstantin and Olivier comments,

Changes since v3:
- added init failure when trying to use in conjunction with multiprocess,
- addressed Andrew comments,

Changes since v2:
- fixed windows build error due to missing trace stub,
- fixed bug when rolling back on lcore register,

Changes since v1:
- rebased on master (conflicts on merged Windows series),
- separated lcore role code cleanup in a patch,
- tried to use a single naming, so kept non-EAL threads as the main
  notion. non-EAL threads are then distinguished between registered and
  unregistered non-EAL threads,
- added unit tests (still missing some coverage, marked with a FIXME),
- reworked callbacks call under a common rwlock lock which protects
  lcores allocations and callbacks registration,
- introduced lcore iterators and converted the bucket mempool driver,

LGTM, just 2 nits see below.
Apart from that:
Series Acked-by: Konstantin Ananyev [off-list ref]

1.
+void
+rte_lcore_callback_unregister(void *handle)
+{
+       struct rte_config *cfg = rte_eal_get_configuration();
+       struct lcore_callback *callback = handle;
+       unsigned int lcore_id;

Seems like forgot to add formal parameter check here:
if (callback == NULL) ... 

+
+       rte_rwlock_write_lock(&lcore_lock);
+       if (callback->uninit == NULL)

2.

+bool
+rte_mp_disable(void)
+{
+       return set_mp_status(MP_STATUS_DISABLED);
+}

Probably name it rte_eal_multiprocess_enable (or so)
to  make it clear from naming and follow
more closely our own name convention.

+
+bool
+eal_enable_multiprocess(void)
+{
+       return set_mp_status(MP_STATUS_ENABLED);
+}

Might be worth to make that function public too.
Then user will have a proper pair to use:
rte_eal_multiprocess_(enable|disable).