[PATCH 1/6] service: reduce statistics overhead for parallel services
Van Haaren, Harry
harry.van.haaren at intel.com
Mon Oct 3 15:03:31 CEST 2022
> -----Original Message-----
> From: Mattias Rönnblom <mattias.ronnblom at ericsson.com>
> Sent: Monday, October 3, 2022 12:37 PM
> To: David Marchand <david.marchand at redhat.com>; Van Haaren, Harry
> <harry.van.haaren at intel.com>
> Cc: dev at dpdk.org; Honnappa Nagarahalli <Honnappa.Nagarahalli at arm.com>;
> Morten Brørup <mb at smartsharesystems.com>; nd <nd at arm.com>
> Subject: Re: [PATCH 1/6] service: reduce statistics overhead for parallel services
<snip>
> > Now, looking at this series, without a cover letter, I had to guess.
> > I saw it is linked to the v1 patch.
> > I "assumed" it was then an alternative, since you had comments on
> > Harry v3 patch, or at least Harry would reply and we could conclude.
> >
>
> Sorry for failing to mention enough context in the patchset. I assumed
> it was Harry and not you that would resolve this issue. Harry's patchset
> fixes the statistics bug related to MT safe services, but does not
> address the performance issue discussed. So Harry's patchset makes sense
> on its own. It also adds a performance test case.
>
> I believe the test case is the only thing left of Harry's improvements
> after my patchset is applied.
>
> My patchset was meant as an improvement on what Harry already had done,
> not as an alternative.
>
> This is all up the maintainer of course, but it seems to me that Harry's
> patchset should go in first, and then mine.
>
> If Harry or you so prefer, I can rework my patchset to apply cleanly
> against current main (i.e., w/o Harry's patches).
I'd like to keep the performance unit-test, but otherwise your patchset is good with me.
(Will test/review the series asap).
> > So what do we do?
> > Should I understand that your comments on Harry series can be ignored
> > and I proceed with all this?
> >
>
> My comments were minor, except those that relates to the issue that my
> follow-up patchset addresses.
>
> > I hope it applies cleanly.
I have no strong opinion here; whatever is easier for maintainers.
More information about the dev
mailing list