Hi Hemant,
> -----Original Message-----
> From: Hemant Agrawal <hemant.agra...@nxp.com>
> Sent: Thursday, January 3, 2019 16:05
> To: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com>; Ruifeng Wang
> (Arm Technology China) <ruifeng.w...@arm.com>; dev@dpdk.org
> Cc: tho...@monjalon.net; jer...@marvell.com; bruce.richard...@intel.com;
> chao...@linux.vnet.ibm.com; nd <n...@arm.com>;
> tomaszx.kula...@intel.com
> Subject: Re: [dpdk-dev] [PATCH v1] examples/l3fwd: enable hash multi
> lookup for ARM
>
>
> On 02-Jan-19 11:53 PM, Honnappa Nagarahalli wrote:
> > Thanks Ruifeng for the patch. I have one question inline.
> >
> > Jerin/Hemant,
> > It would be good if you could test this on your platforms, since this is
> being made default.
> >
> > Thanks,
> > Honnappa
> >
> >> -----Original Message-----
> >> From: Ruifeng Wang <ruifeng.w...@arm.com>
> >> Sent: Tuesday, January 1, 2019 11:28 PM
> >> To: dev@dpdk.org
> >> Cc: tho...@monjalon.net; jer...@marvell.com;
> hemant.agra...@nxp.com;
> >> bruce.richard...@intel.com; chao...@linux.vnet.ibm.com; Honnappa
> >> Nagarahalli <honnappa.nagaraha...@arm.com>; nd <n...@arm.com>;
> Ruifeng
> >> Wang (Arm Technology China) <ruifeng.w...@arm.com>;
> >> tomaszx.kula...@intel.com
> >> Subject: [PATCH v1] examples/l3fwd: enable hash multi lookup for ARM
> >>
> >> Compile option for hash_multi_lookup was broken, and caused feature
> >> cannot be enabled on Arm.
> >> This patch sets hash_multi_lookup method as default, and sequential
> >> lookup becomes optional.
> >>
> >> In test of 8192 flows with 128-byte packets, throughput increased by
> >> 25.6% after enabling hash_multi_lookup.
>
> Hi,
>
> I tested this patch on LS2088 (A72) platform. I have tried both dpaa2 and
> armv8a config for builds.
>
> In both cases, I am seeing a drop of 3-8% in different scenario using 1 core
> case with small packets.
>
> - 1 flow case - 7-8 % drop in performance
>
> - 8 K flow case - 2-5 % drop in performance
>
>
> Regards,
>
> Hemant
>
Thanks for your tests.
Were the 8K flow in your case all for hit?
Not know why, but in my tests, 1 core case with 64B packet had notable
performance gain with 8K flow.
Although performance had drop with few hash entry configured.
Command used:
./l3fwd -n 4 -c 0x80 -- -E -P --parse-ptype -p 0x3 --config="(0,0,7),(1,0,7)"
--hash-entry-num=0x8000
> > I assume these are lookup-hit numbers. Do you have look-up miss
> numbers?
> >
> >> Fixes: 52c97adc1f0f ("examples/l3fwd: fix exact match performance")
> >> Cc: tomaszx.kula...@intel.com
> >>
> >> Signed-off-by: Ruifeng Wang <ruifeng.w...@arm.com>
> >> Reviewed-by: Gavin Hu <gavin...@arm.com>
> >> Reviewed-by: Phil Yang <phil.y...@arm.com>
> >> Tested-by: Ruifeng Wang <ruifeng.w...@arm.com>
> >> ---
> >> examples/l3fwd/l3fwd.h | 4 ----
> >> 1 file changed, 4 deletions(-)
> >>
> >> diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h index
> >> c962deac3..063b80018 100644
> >> --- a/examples/l3fwd/l3fwd.h
> >> +++ b/examples/l3fwd/l3fwd.h
> >> @@ -11,10 +11,6 @@
> >>
> >> #define RTE_LOGTYPE_L3FWD RTE_LOGTYPE_USER1
> >>
> >> -#if !defined(NO_HASH_MULTI_LOOKUP) &&
> >> defined(RTE_MACHINE_CPUFLAG_NEON) -#define
> NO_HASH_MULTI_LOOKUP 1
> >> -#endif
> >> -
> >> #define MAX_PKT_BURST 32
> >> #define BURST_TX_DRAIN_US 100 /* TX drain every ~100us */
> >>
> >> --
> >> 2.17.1
