>-----Original Message-----
>From: Thomas Monjalon <tho...@monjalon.net>
>Sent: Monday, April 6, 2020 7:07 PM
>To: Pavan Nikhilesh Bhagavatula <pbhagavat...@marvell.com>
>Cc: Ori Kam <or...@mellanox.com>; Jerin Jacob Kollanukkaran
><jer...@marvell.com>; xiang.w.w...@intel.com; dev@dpdk.org;
>Shahaf Shuler <shah...@mellanox.com>; hemant.agra...@nxp.com;
>Opher Reviv <op...@mellanox.com>; Alex Rosenbaum
><al...@mellanox.com>; Dovrat Zifroni <dov...@marvell.com>; Prasun
>Kapoor <pkap...@marvell.com>; nipun.gu...@nxp.com;
>bruce.richard...@intel.com; yang.a.h...@intel.com;
>harry.ch...@intel.com; gu.ji...@zte.com.cn;
>shanjia...@chinatelecom.cn; zhangy....@chinatelecom.cn;
>lixin...@huachentel.com; wush...@inspur.com;
>yuying...@yxlink.com; fanchengg...@sunyainfo.com;
>davidf...@tencent.com; liuzho...@chinaunicom.cn;
>zhaoyon...@huawei.com; o...@yunify.com; j...@netgate.com;
>hongjun...@intel.com; j.bromh...@titan-ic.com; d...@ntop.org;
>f...@napatech.com; arthur...@lionic.com; david.march...@redhat.com
>Subject: Re: [EXT] [PATCH v1 4/4] regexdev: implement regex rte level
>functions
>
>06/04/2020 15:22, Pavan Nikhilesh Bhagavatula:
>> >06/04/2020 14:33, Pavan Nikhilesh Bhagavatula:
>> >> >> From: Pavan Nikhilesh Bhagavatula
>> >> >> > >+uint16_t
>> >> >> > >+rte_regexdev_enqueue_burst(uint8_t dev_id, uint16_t
>> >qp_id,
>> >> >> > >+ struct rte_regex_ops **ops, uint16_t
>> >nb_ops)
>> >> >> > >+{
>> >> >> > >+ return regex_devices[dev_id]-
>> >> >> > >>enqueue(regex_devices[dev_id], qp_id,
>> >> >> > >+ ops, nb_ops);
>> >> >> > >+}
>> >> >> >
>> >> >> > Move these functions to .h in-lining them.
>> >> >> > Also, please add debug checks @see
>> >> >rte_eth_rx_burst/rte_eth_tx_burst.
>> >> >>
>> >> >> O.K will update.
>> >> >
>> >> >In general, inlining is a pain for ABI compatibility.
>> >> >Please inline only if the gain is very significant.
>> >> >
>> >>
>> >> The performance gain mostly comes from hoisting
>> >`regex_devices[dev_id]` load above the
>> >> poll loop.
>> >> Since, the performance measurement application is still in pipeline
>> >and regexdev would be
>> >> experimental for next couple of releases I suggest inlining it now
>and
>> >worrying about ABI when
>> >> experimental tag needs to be removed.
>> >
>> >No, we must worry about ABI from the beginning.
>>
>> I though performance was the primary objective :-).
>
>It is.
>
>> >> We can follow the same path as done by ethdev
>> >[https://urldefense.proofpoint.com/v2/url?u=https-
>3A__www.mail-
>> >2Darchive.com_dev-
>>
>>40dpdk.org_msg142392.html&d=DwICAg&c=nKjWec2b6R0mOyPaz7xt
>f
>> >Q&r=E3SgYMjtKCMVsB-fmvgGV3o-
>> >g_fjLhk5Pupi9ijohpc&m=7Gqb6WKmZV5uY3xa7FRVrRVDz8Usrsd-
>>
>>rDjIKr6CUQQ&s=sQo2Kx9fzTNXwiQ2Fzki3s5GSuiiAEzz2VtN68_KKXo&e
>=
>> >]
>> >
>> >ethdev is not an argument.
>>
>> What about ring? [https://urldefense.proofpoint.com/v2/url?u=http-
>3A__mails.dpdk.org_archives_dev_2020-
>2DApril_161506.html&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3S
>gYMjtKCMVsB-fmvgGV3o-
>g_fjLhk5Pupi9ijohpc&m=u9gnM_YrOJDusN4yR8YUcUuUkri4tOjnHrQ0A
>Qd5zTw&s=uv6AQA-
>Zu7o6ugyhpGHLxFOk4SfEdkHfFGDmhzANRME&e= ]
>>
>> Why do we need to prove the same performance advantage using in-
>lining for datapath
>> critical functions again and again?
>
>Because every libraries have not the same usage and load.
>We should compare how much cycle is saved with inline vs
>how much cycles is, "in average", a regex burst?
>
>If you tell me regex processing is fast, OK, let's inline.
>
Regex processing speed would still be dependent on underlying device
capabilities.
All we are trying to do is reduce the enqueue/dequeue completion time which
would
bring down the overall latency.
Thanks,
Pavan.
