On 28-Mar-18 12:26 PM, Thomas Monjalon wrote:
28/03/2018 12:42, Burakov, Anatoly:
On 28-Mar-18 10:53 AM, Thomas Monjalon wrote:
28/03/2018 11:21, Burakov, Anatoly:
I'm not against trying to improve the core design. I'm just saying that,
had this kind of feedback been provided just a bit earlier, I would've
had time to fix it in time for deadlines. However, because memory rework
patchset depends on this API, i would suggest merging it in now, as is,
and commit to a roadmap of improvements for next release(s).
Actually, you had the feedback yourself from the beginning.
You decided to gave up with interrupt thread because its implementation
is not complete (and maybe far from perfect).
That's not quite how i see it, but OK, suppose so.
There are some communities where it is not acceptable to workaround
core issues because of timing issues. I think we accept it in DPDK,
but I continue to question it, in order to be sure that everybody is OK
with this kind of tradeoff.
The way i see it, not all API's are equal; some are more important than
others. This is a new, experimental API that is not core to any DPDK
function - it's not used on any hotpaths nor is it even that demanding
(the two threads will be sleeping 99.999% of the time anyway). I think
we're allowed to experiment on it before settling on an implementation
that satisfies everyone :)
For starters, we could plan on removing alarm thread's dependency on
rte_malloc and just use regular malloc API's in there, and rework
asynchronous IPC API to use that instead. This shouldn't be much work,
and will presumably make you halfway happy, as one of the threads will
be gone :)
We can then look into removing the second thread and moving the entirety
of DPDK IPC into the interrupt thread. I'm not too sure how would that
work, but i haven't looked at it in any detail, so maybe it is feasible.
Can we agree on this? It would be great to do everything perfectly from
the first try, but having a goal in sight and working towards it is fine
too, even if not all of the steps we take are perfect.
The main concern is API.
If all these changes are internal only, and does not involve any major
API change, then I guess it is OK to pospone them in next release.
Yes, all of this is/will be internal to DPDK IPC - no externally visible
changes whatsoever.
--
Thanks,
Anatoly
