From: Ori Kam <orika@mellanox.com>
To: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>,
Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
"xiang.w.wang@intel.com" <xiang.w.wang@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
Shahaf Shuler <shahafs@mellanox.com>,
"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
Opher Reviv <opher@mellanox.com>,
Alex Rosenbaum <alexr@mellanox.com>,
Dovrat Zifroni <dovrat@marvell.com>,
Prasun Kapoor <pkapoor@marvell.com>,
"nipun.gupta@nxp.com" <nipun.gupta@nxp.com>,
"bruce.richardson@intel.com" <bruce.richardson@intel.com>,
"yang.a.hong@intel.com" <yang.a.hong@intel.com>,
"harry.chang@intel.com" <harry.chang@intel.com>,
"gu.jian1@zte.com.cn" <gu.jian1@zte.com.cn>,
"shanjiangh@chinatelecom.cn" <shanjiangh@chinatelecom.cn>,
"zhangy.yun@chinatelecom.cn" <zhangy.yun@chinatelecom.cn>,
"lixingfu@huachentel.com" <lixingfu@huachentel.com>,
"wushuai@inspur.com" <wushuai@inspur.com>,
"yuyingxia@yxlink.com" <yuyingxia@yxlink.com>,
"fanchenggang@sunyainfo.com" <fanchenggang@sunyainfo.com>,
"davidfgao@tencent.com" <davidfgao@tencent.com>,
"liuzhong1@chinaunicom.cn" <liuzhong1@chinaunicom.cn>,
"zhaoyong11@huawei.com" <zhaoyong11@huawei.com>,
"oc@yunify.com" <oc@yunify.com>,
"jim@netgate.com" <jim@netgate.com>,
"hongjun.ni@intel.com" <hongjun.ni@intel.com>,
"j.bromhead@titan-ic.com" <j.bromhead@titan-ic.com>,
"deri@ntop.org" <deri@ntop.org>,
"fc@napatech.com" <fc@napatech.com>,
"arthur.su@lionic.com" <arthur.su@lionic.com>,
Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [dpdk-dev] [RFC v6] regexdev: introduce regexdev subsystem
Date: Thu, 12 Mar 2020 12:13:53 +0000 [thread overview]
Message-ID: <AM6PR05MB517618E3837DA78D2071A05EDBFD0@AM6PR05MB5176.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <AM6PR05MB5176FD8FC686F83A9F3EF7FCDBFF0@AM6PR05MB5176.eurprd05.prod.outlook.com>
Hi All,
If there are no more comments, I'm starting to implement the new class.
Thanks,
Ori
> -----Original Message-----
> From: Ori Kam
> Sent: Tuesday, March 10, 2020 7:00 PM
> To: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Jerin Jacob
> Kollanukkaran <jerinj@marvell.com>; xiang.w.wang@intel.com
> Cc: dev@dpdk.org; Shahaf Shuler <shahafs@mellanox.com>;
> hemant.agrawal@nxp.com; Opher Reviv <opher@mellanox.com>; Alex
> Rosenbaum <Alexr@mellanox.com>; Dovrat Zifroni <dovrat@marvell.com>;
> Prasun Kapoor <pkapoor@marvell.com>; nipun.gupta@nxp.com;
> bruce.richardson@intel.com; yang.a.hong@intel.com; harry.chang@intel.com;
> gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com; wushuai@inspur.com;
> yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
> davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
> zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
> hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
> fc@napatech.com; arthur.su@lionic.com; Thomas Monjalon
> <thomas@monjalon.net>
> Subject: RE: [dpdk-dev] [RFC v6] regexdev: introduce regexdev subsystem
>
> Hi Pavan,
>
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Pavan Nikhilesh
> Bhagavatula
> > Sent: Tuesday, March 10, 2020 6:37 PM
> > To: Ori Kam <orika@mellanox.com>; Jerin Jacob Kollanukkaran
> > <jerinj@marvell.com>; xiang.w.wang@intel.com
> > Cc: dev@dpdk.org; Shahaf Shuler <shahafs@mellanox.com>;
> > hemant.agrawal@nxp.com; Opher Reviv <opher@mellanox.com>; Alex
> > Rosenbaum <alexr@mellanox.com>; Dovrat Zifroni <dovrat@marvell.com>;
> > Prasun Kapoor <pkapoor@marvell.com>; nipun.gupta@nxp.com;
> > bruce.richardson@intel.com; yang.a.hong@intel.com;
> harry.chang@intel.com;
> > gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> > zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com;
> wushuai@inspur.com;
> > yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
> > davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
> > zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
> > hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
> > fc@napatech.com; arthur.su@lionic.com; Thomas Monjalon
> > <thomas@monjalon.net>
> > Subject: Re: [dpdk-dev] [RFC v6] regexdev: introduce regexdev subsystem
> >
> > Hi Ori,
> > >
> > >Hi Pavan,
> > >
> > >> -----Original Message-----
> > >> From: dev <dev-bounces@dpdk.org> On Behalf Of Pavan Nikhilesh
> > >Bhagavatula
> > >> Sent: Tuesday, March 10, 2020 3:42 PM
> > >> To: Ori Kam <orika@mellanox.com>; Jerin Jacob Kollanukkaran
> > >> <jerinj@marvell.com>; xiang.w.wang@intel.com
> > >> Cc: dev@dpdk.org; Shahaf Shuler <shahafs@mellanox.com>;
> > >> hemant.agrawal@nxp.com; Opher Reviv <opher@mellanox.com>;
> > >Alex
> > >> Rosenbaum <alexr@mellanox.com>; Dovrat Zifroni
> > ><dovrat@marvell.com>;
> > >> Prasun Kapoor <pkapoor@marvell.com>; nipun.gupta@nxp.com;
> > >> bruce.richardson@intel.com; yang.a.hong@intel.com;
> > >harry.chang@intel.com;
> > >> gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn;
> > >> zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com;
> > >wushuai@inspur.com;
> > >> yuyingxia@yxlink.com; fanchenggang@sunyainfo.com;
> > >> davidfgao@tencent.com; liuzhong1@chinaunicom.cn;
> > >> zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com;
> > >> hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org;
> > >> fc@napatech.com; arthur.su@lionic.com; Thomas Monjalon
> > >> <thomas@monjalon.net>
> > >> Subject: Re: [dpdk-dev] [RFC v6] regexdev: introduce regexdev
> > >subsystem
> > >>
> > >> Hi Ori,
> > >>
> > >> <snip>
> > >>
> > >> >+
> > >> >+/**
> > >> >+ * The generic *rte_regex_ops* structure to hold the RegEx
> > >attributes
> > >> >+ * for enqueue and dequeue operation.
> > >> >+ */
> > >> >+struct rte_regex_ops {
> > >> >+ /* W0 */
> > >> >+ uint16_t req_flags;
> > >> >+ /**< Request flags for the RegEx ops.
> > >> >+ * @see RTE_REGEX_OPS_REQ_*
> > >> >+ */
> > >> >+ uint16_t rsp_flags;
> > >> >+ /**< Response flags for the RegEx ops.
> > >> >+ * @see RTE_REGEX_OPS_RSP_*
> > >> >+ */
> > >> >+ uint16_t nb_actual_matches;
> > >> >+ /**< The total number of actual matches detected by the
> > >> >Regex device.*/
> > >> >+ uint16_t nb_matches;
> > >> >+ /**< The total number of matches returned by the RegEx
> > >> >device for this
> > >> >+ * scan. The size of *rte_regex_ops::matches* zero length array
> > >> >will be
> > >> >+ * this value.
> > >> >+ *
> > >> >+ * @see struct rte_regex_ops::matches, struct
> > >> >rte_regex_match
> > >> >+ */
> > >> >+
> > >> >+ /* W1 */
> > >> >+ struct rte_mbuf *mbuf; /**< source mbuf, to search in. */
> > >>
> > >> While implementing pcre2 SW driver I came across an oddity where
> > >having
> > >> mbuf alone
> > >> wouldn’t suffice, we need to have scan start offset and scan length as
> > >generally
> > >> we would skip the
> > >> L2/L3 header.
> > >>
> > >
> > >Yes you are correct, in most cases the application will need
> > >not the all mbuf or it will connect number of mbuf.
> > >This can be acchived by modifying the mbuf to point to the correct data
> > >start, and decrease the len.
> >
> > Wouldn’t that complicate Txing the packet later on after dequeue from regex
> if
> > the user decides to do so?.
> > Instead we can have two fields in rte_regex_ops for storing scan_start_offset
> > and
> > scan_size
> >
> The user will need to return the packet to the original state. I agree that
> that it is a bit harder for the application (but not by much). But in any case the
> user knows
> the size he removed so when done he just need to return to the original value.
> on the other end it save the user the working with iov structs.
>
> Regarding your idea about start_offset and scan_size. It is a nice idea,
> But I don't think it is worth it, since the start_offset is just what the user
> needs to keep in order to return the mbuf to original state.
> Also if the user wants to combine number of messages, he can't use this
> approach since he will need to remove the header also from the second
> message and bind the two messages. So in any case the user must have some
> logic.
>
> > >In one of the previous version we used buffer address and iov to solve
> > >this issue. But in order to keep the API the same as crypto we decided
> > >to go
> > >with mbuf.
> >
> > The general idea was to save cycles converting mbuf and chain of mbuf to iov
> > and back not
> > just to stay in line with crypto.
> >
>
> I agree and this was also my main thinking but Jerin and other community
> members raised
> this approach.
> Each approach has advantages and disadvantages.
> If the user wants he can just give the all mbuf. Also since at least in some
> cases the regex will be done after crypto it make sense to use the same structs.
> There is also the advantage of sharing code between all the drivers.
> (net/crypto/regex)
> which can be done when using mbuf. (for example memory registration)
>
> > >This API is experimental and based on the usage we might change it to
> > >iov.
> > >
> > >> >+
> > >> >+ /* W2 */
> > >> >+ uint16_t group_id0;
> > >> >+ /**< First group_id to match the rule against. At minimum one
> > >> >group
> > >> >+ * should be valid. Behaviour is undefined non of the groups are
> > >> >valid.
> > >> >+ *
> > >> >+ * @see RTE_REGEX_OPS_REQ_GROUP_ID0_VALID_F
> > >> >+ */
> > >> >+ uint16_t group_id1;
> > >> >+ /**< Second group_id to match the rule against.
> > >> >+ *
> > >> >+ * @see RTE_REGEX_OPS_REQ_GROUP_ID1_VALID_F
> > >> >+ */
> > >> >+ uint16_t group_id2;
> > >> >+ /**< Third group_id to match the rule against.
> > >> >+ *
> > >> >+ * @see RTE_REGEX_OPS_REQ_GROUP_ID2_VALID_F
> > >> >+ */
> > >> >+ uint16_t group_id3;
> > >> >+ /**< Forth group_id to match the rule against.
> > >> >+ *
> > >> >+ * @see RTE_REGEX_OPS_REQ_GROUP_ID3_VALID_F
> > >> >+ */
> > >> >+
> > >> >+ /* W3 */
> > >> >+ RTE_STD_C11
> > >> >+ union {
> > >> >+ uint64_t user_id;
> > >> >+ /**< Application specific opaque value. An application
> > >> >may use
> > >> >+ * this field to hold application specific value to share
> > >> >+ * between dequeue and enqueue operation.
> > >> >+ * Implementation should not modify this field.
> > >> >+ */
> > >> >+ void *user_ptr;
> > >> >+ /**< Pointer representation of *user_id* */
> > >> >+ };
> > >> >+
> > >> >+ /* W4 */
> > >> >+ struct rte_regex_match matches[];
> > >> >+ /**< Zero length array to hold the match tuples.
> > >> >+ * The struct rte_regex_ops::nb_matches value holds the
> > >> >number of
> > >> >+ * elements in this array.
> > >> >+ *
> > >> >+ * @see struct rte_regex_ops::nb_matches
> > >> >+ */
> > >> >+};
> > >> >+
> > >>
> > >> Thanks,
> > >> Pavan.
> > >
> > >Thanks,
> > >Ori
next prev parent reply other threads:[~2020-03-12 12:13 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-27 15:50 [dpdk-dev] [RFC PATCH v1] regexdev: introduce regexdev subsystem jerinj
2019-07-15 4:26 ` Jerin Jacob Kollanukkaran
2019-08-15 9:35 ` Thomas Monjalon
2019-08-15 11:34 ` Thomas Monjalon
2019-08-19 3:09 ` Jerin Jacob Kollanukkaran
2019-08-20 1:54 ` Wang, Xiang W
2019-09-10 8:05 ` Jerin Jacob Kollanukkaran
2019-09-19 13:58 ` Wang Xiang
2019-09-27 14:35 ` Jerin Jacob Kollanukkaran
2019-10-14 13:59 ` Wang Xiang
2020-01-26 11:55 ` Ori Kam
2019-08-21 5:32 ` Shahaf Shuler
2019-08-21 15:12 ` John Bromhead
2019-09-10 10:31 ` Jerin Jacob Kollanukkaran
2019-09-10 11:02 ` Jerin Jacob Kollanukkaran
2019-09-27 14:45 ` Jerin Jacob Kollanukkaran
2019-10-02 5:53 ` Shahaf Shuler
2019-10-02 8:31 ` Jerin Jacob Kollanukkaran
2019-10-02 8:52 ` Shahaf Shuler
2019-10-02 9:34 ` Jerin Jacob Kollanukkaran
2020-01-27 21:19 ` [dpdk-dev] [PATCH v2] net/regexdev: " Ori Kam
2020-01-28 9:00 ` [dpdk-dev] [PATCH v3] regexdev: " Ori Kam
2020-02-22 16:52 ` Jerin Jacob
2020-02-23 8:41 ` Ori Kam
2020-02-23 9:53 ` Jerin Jacob
2020-02-23 12:33 ` Ori Kam
2020-02-25 5:57 ` Jerin Jacob
2020-02-25 7:48 ` Ori Kam
2020-02-26 9:03 ` Wang Xiang
2020-02-26 8:36 ` Ori Kam
2020-02-27 9:25 ` Wang Xiang
2020-02-27 7:31 ` Ori Kam
2020-02-27 9:16 ` Wang Xiang
2020-02-27 14:40 ` [dpdk-dev] [RFC v4] " Ori Kam
2020-02-27 14:55 ` Jerin Jacob
2020-02-27 15:08 ` [dpdk-dev] [RFC v5] " Ori Kam
2020-03-01 6:13 ` [dpdk-dev] [EXT] " Pavan Nikhilesh Bhagavatula
2020-03-01 7:31 ` Ori Kam
2020-03-01 13:23 ` Pavan Nikhilesh Bhagavatula
2020-03-01 14:10 ` Ori Kam
2020-03-01 14:38 ` Pavan Nikhilesh Bhagavatula
2020-03-01 15:41 ` Ori Kam
2020-03-01 15:57 ` Pavan Nikhilesh Bhagavatula
2020-03-02 7:18 ` Jerin Jacob
2020-03-03 7:06 ` Ori Kam
2020-03-02 7:05 ` [dpdk-dev] " Wang Xiang
2020-03-03 7:44 ` Ori Kam
2020-03-03 7:54 ` Jerin Jacob
2020-03-10 10:32 ` [dpdk-dev] [RFC v6] " Ori Kam
2020-03-10 13:42 ` Pavan Nikhilesh Bhagavatula
2020-03-10 16:23 ` Ori Kam
2020-03-10 16:36 ` Pavan Nikhilesh Bhagavatula
2020-03-10 17:00 ` Ori Kam
2020-03-12 12:13 ` Ori Kam [this message]
2020-03-13 1:20 ` Wang Xiang
2020-03-15 10:05 ` Ori Kam
2020-03-16 1:25 ` Wang Xiang
2020-03-16 9:09 ` Ori Kam
2020-03-16 20:48 ` Wang Xiang
2020-03-16 13:49 ` Ori Kam
2020-03-16 21:10 ` Wang Xiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AM6PR05MB517618E3837DA78D2071A05EDBFD0@AM6PR05MB5176.eurprd05.prod.outlook.com \
--to=orika@mellanox.com \
--cc=alexr@mellanox.com \
--cc=arthur.su@lionic.com \
--cc=bruce.richardson@intel.com \
--cc=davidfgao@tencent.com \
--cc=deri@ntop.org \
--cc=dev@dpdk.org \
--cc=dovrat@marvell.com \
--cc=fanchenggang@sunyainfo.com \
--cc=fc@napatech.com \
--cc=gu.jian1@zte.com.cn \
--cc=harry.chang@intel.com \
--cc=hemant.agrawal@nxp.com \
--cc=hongjun.ni@intel.com \
--cc=j.bromhead@titan-ic.com \
--cc=jerinj@marvell.com \
--cc=jim@netgate.com \
--cc=liuzhong1@chinaunicom.cn \
--cc=lixingfu@huachentel.com \
--cc=nipun.gupta@nxp.com \
--cc=oc@yunify.com \
--cc=opher@mellanox.com \
--cc=pbhagavatula@marvell.com \
--cc=pkapoor@marvell.com \
--cc=shahafs@mellanox.com \
--cc=shanjiangh@chinatelecom.cn \
--cc=thomas@monjalon.net \
--cc=wushuai@inspur.com \
--cc=xiang.w.wang@intel.com \
--cc=yang.a.hong@intel.com \
--cc=yuyingxia@yxlink.com \
--cc=zhangy.yun@chinatelecom.cn \
--cc=zhaoyong11@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).