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

Jerin Jacob jerinjacobk at gmail.com
Wed Oct 14 12:09:52 CEST 2020


On Wed, Oct 14, 2020 at 2:02 PM Nicolau, Radu <radu.nicolau at intel.com> wrote:
>
>
> 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.

Ok. Looks good to me. @Honnappa Nagarahalli @Ananyev, Konstantin  ,
I will merge this patch if there are no more objections for v3.


More information about the dev mailing list