[dpdk-dev] [PATCH v3 9/9] mempool/bucket: handle non-EAL lcores
Andrew Rybchenko
arybchenko at solarflare.com
Fri Jun 26 16:34:50 CEST 2020
On 6/26/20 5:13 PM, David Marchand wrote:
> On Tue, Jun 23, 2020 at 7:28 PM Andrew Rybchenko
> <arybchenko at solarflare.com> wrote:
>>
>> On 6/22/20 4:25 PM, David Marchand wrote:
>>> Convert to new lcore API to support non-EAL lcores.
>>>
>>> Signed-off-by: David Marchand <david.marchand at redhat.com>
>>> ---
[snip]
>>> + bd->adoption_buffer_rings[lcore_id] = rte_ring_create(rg_name,
>>> + rte_align32pow2(mp->size + 1), mp->socket_id, rg_flags);
>>> + if (bd->adoption_buffer_rings[lcore_id] == NULL)
>>> + goto error;
>>>
>>> - return count;
>>> + return 0;
>>> +error:
>>> + rte_free(bd->buckets[lcore_id]);
>>> + bd->buckets[lcore_id] = NULL;
>>> + return -1;
>>
>> Why does the API collapse all negative errnos into -1?
>> (I don't think it is critical, just want to know why).
>
> I collapsed everything as a single error as we have a partial idea of
> what went wrong when calling this callback with all lcores at
> registration.
> We could get a specific error reported by this callback, but then we
> would not know on which lcore (programmatically).
> And in the end, all errors will summarize as a lack of resources, I do
> not expect a need for input validation.
Makes sense. Thanks for explanations.
> Maybe you have other use cases in mind?
No.
More information about the dev
mailing list