[dpdk-dev] [PATCH v1] event/sw: performance improvements

Nicolau, Radu radu.nicolau at intel.com
Wed Oct 14 10:32:23 CEST 2020


On 10/13/2020 8:11 PM, Jerin Jacob wrote:
> On Wed, Oct 7, 2020 at 4:22 PM Ananyev, Konstantin
> <konstantin.ananyev at intel.com> wrote:
>>> On 10/6/2020 11:13 AM, Ananyev, Konstantin wrote:
>>>>>> -----Original Message-----
>>>>>> From: Jerin Jacob <jerinjacobk at gmail.com>
>>>>>> Sent: Monday, October 5, 2020 5:35 PM
>>>>>> To: Nicolau, Radu <radu.nicolau at intel.com>
>>>>>> Cc: Honnappa Nagarahalli <Honnappa.Nagarahalli at arm.com>; Richardson, Bruce
>>>>>> <bruce.richardson at intel.com>; Ananyev, Konstantin
>>>>>> <konstantin.ananyev at intel.com>; Van Haaren, Harry
>>>>>> <harry.van.haaren at intel.com>; dev at dpdk.org; jerinj at marvell.com; nd
>>>>>> <nd at arm.com>
>>>>>> Subject: Re: [dpdk-dev] [PATCH v1] event/sw: performance improvements
>>>>>>
>>>>>> On Tue, Sep 29, 2020 at 2:32 PM Nicolau, Radu <radu.nicolau at intel.com> wrote:
> a concern that another library not uses public ring API,
>>>> but instead accesses ring internals directly. Obviously such coding practice is not welcomed
>>>> as it makes harder to maintain/extend ring library in future.
>>>> About 2) - these new API can(/shoud) be marked an experimental anyway.
>>>> As another thing - it is still unclear what a performance gain we are talking about here.
>>>> Is it really worth it comparing to just using SP/SC?
>>> The change itself came after I analyzed the memory bound sections of the
>>> code, and I just did a quick test, I got about 3.5% improvement in
>>> throughput,  maybe not so much but significant for such a small change,
>>> and depending on the usecase it may be more.
>>>
>>> As for the implementation itself, I would favour having a custom ring
>>> like container in the PMD code, this will solve the issue of using
>>> rte_ring internals while still allow for full optimisation. If this is
>>> acceptable, I will follow up by tomorrow.
>> Sounds ok to me.
> Nicolau Radu,
>
> Could you supersede this patch, if the plan is to send it to a new
> version based on a custom ring?
The v3 (https://patchwork.dpdk.org/patch/79879/) sent last week 
implements the custom ring and does not use the rte_ring internals. v1 
and v2 are superseded.


More information about the dev mailing list