[dpdk-dev] [EXT] [PATCH v1 4/4] regexdev: implement regex rte level functions

[Pavan Nikhilesh Bhagavatula]

>-----Original Message-----
>From: Thomas Monjalon <thomas at monjalon.net>
>Sent: Monday, April 6, 2020 7:07 PM
>To: Pavan Nikhilesh Bhagavatula <pbhagavatula at marvell.com>
>Cc: Ori Kam <orika at mellanox.com>; Jerin Jacob Kollanukkaran
><jerinj at marvell.com>; xiang.w.wang at intel.com; dev at dpdk.org;
>Shahaf Shuler <shahafs at mellanox.com>; hemant.agrawal at nxp.com;
>Opher Reviv <opher at mellanox.com>; Alex Rosenbaum
><alexr at mellanox.com>; Dovrat Zifroni <dovrat at marvell.com>; Prasun
>Kapoor <pkapoor at marvell.com>; nipun.gupta at nxp.com;
>bruce.richardson at intel.com; yang.a.hong at intel.com;
>harry.chang at intel.com; gu.jian1 at zte.com.cn;
>shanjiangh at chinatelecom.cn; zhangy.yun at chinatelecom.cn;
>lixingfu at huachentel.com; wushuai at inspur.com;
>yuyingxia at yxlink.com; fanchenggang at sunyainfo.com;
>davidfgao at tencent.com; liuzhong1 at chinaunicom.cn;
>zhaoyong11 at huawei.com; oc at yunify.com; jim at netgate.com;
>hongjun.ni at intel.com; j.bromhead at titan-ic.com; deri at ntop.org;
>fc at napatech.com; arthur.su at lionic.com; david.marchand at 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.