From: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
To: 'Shahaf Shuler' <shahafs@mellanox.com>,
'Thomas Monjalon' <thomas@monjalon.net>,
"'dev@dpdk.org'" <dev@dpdk.org>
Cc: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>,
'Hemant Agrawal' <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' <nipun.gupta@nxp.com>,
"'Wang, Xiang W'" <xiang.w.wang@intel.com>,
"'Richardson, Bruce'" <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>
Subject: Re: [dpdk-dev] [RFC PATCH v1] regexdev: introduce regexdev subsystem
Date: Fri, 27 Sep 2019 14:45:42 +0000 [thread overview]
Message-ID: <BYAPR18MB24242933C05C327077DCCCD8C8810@BYAPR18MB2424.namprd18.prod.outlook.com> (raw)
In-Reply-To: <BYAPR18MB2424E5D448C0D2DCD1ADD6D0C8B60@BYAPR18MB2424.namprd18.prod.outlook.com>
> -----Original Message-----
> From: Jerin Jacob Kollanukkaran
> Sent: Tuesday, September 10, 2019 4:33 PM
> To: Shahaf Shuler <shahafs@mellanox.com>; Thomas Monjalon
> <thomas@monjalon.net>; dev@dpdk.org
> Cc: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant
> Agrawal <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
> <nipun.gupta@nxp.com>; Wang, Xiang W <xiang.w.wang@intel.com>;
> Richardson, Bruce <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
> Subject: RE: [dpdk-dev] [RFC PATCH v1] regexdev: introduce regexdev
> subsystem
>
> > Hi Jerin,
>
> Hi Shahaf,
>
> Sorry for delay in response(Was busy with 19.11 proposal deadline). Please see
> inline.
>
> > >
> > > RegEx pattern matching applications:
> > > • Next Generation Firewalls (NGFW)
> > > • Deep Packet and Flow Inspection (DPI) • Intrusion Prevention
> > > Systems (IPS) • DDoS Mitigation • Network Monitoring • Data Loss
> > > Prevention (DLP) • Smart NICs • Grammar based content processing •
> > > URL, spam and adware filtering • Advanced auditing and policing of
> > > user/application security policies • Financial data mining - parsing
> > > of streamed financial feeds
> >
> > I think two more important use case to add (at least on the doc of
> > this
> > subsystem) are:
> > * application recognition
> > * memory introspection
>
> Sure. Will add the following from John as well.
>
> # Natural Language Processing (NLP)
> # Sentiment Analysis
> # Big Data database acceleration (Spark, Hadoop etc.) # Computational Storage
>
> >
> >
> > > +/**
> > > + * Update the rule database of a RegEx device.
> > > + *
> > > + * @param dev_id RegEx device identifier
> > > + * @param rules
> > > + * Points to an array of *nb_rules* objects of type *rte_regex_rule*
> > > structure
> > > + * which contain the regex rules attributes to be updated in rule
> database.
> > > + * @param nb_rules
> > > + * The number of PCRE rules to update the rule database.
> > > + *
> > > + * @return
> > > + * The number of regex rules actually updated on the regex device's rule
> > > + * database. The return value can be less than the value of the *nb_rules*
> > > + * parameter when the regex devices fails to update the rule database or
> > > + * if invalid parameters are specified in a *rte_regex_rule*.
> > > + * If the return value is less than *nb_rules*, the remaining PCRE rules
> > > + * at the end of *rules* are not consumed and the caller has to take
> > > + * care of them and rte_errno is set accordingly.
> > > + * Possible errno values include:
> > > + * - -EINVAL: Invalid device ID or rules is NULL
> > > + * - -ENOTSUP: The last processed rule is not supported on this device.
> > > + * - -ENOSPC: No space available in rule database.
> > > + *
> > > + * @see rte_regex_rule_db_import(), rte_regex_rule_db_export() */
> > > +uint16_t rte_regex_rule_db_update(uint8_t dev_id, const struct
> > > +rte_regex_rule
> > > *rules,
> > > + uint16_t nb_rules);
> >
> > I think the function name is not too informative. If this function
> > meant to compile the rule then it should be explicit on the function name.
>
> It is meant to be compile the rules and then update the rule database.
>
> I think, we can have either 1 or 2. Let me know your preference or If you have
> any name suggestion. I will change it accordingly.
>
> 1. rte_regex_rule_db_compile()
> 2. rte_regex_rule_db_compile_update()
@Shahaf Shuler, Thoughts?
>
>
> > > +
> > > + */
> > > +struct rte_regex_ops {
> > > +
> > > + /* W4 */
> > > + 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* */
> > > + };
> >
> > Since we target the regex subsystem for both regex and DPI I think it
> > will be good to add another uint64_t field called connection_id.
> > Device that support DPI can refer to it as another match able field
> > when looking up for matches on the given buffer.
> >
> > This field is different from the user_id, as it is not opaque for the device.
>
> Is this driver specific storage place where application should not touch it?
>
> If not, Could you share the data flow of this field? Ie. Who "write" this Field and
> who "read" this field.
@Shahaf Shuler Thoughts?
Based on your input, I will update the next version.
>
> This is just for documentation, In any event we can add new fields.
>
> If it is only for driver usage then I think, some driver may need more 8B
> Storage. In that case I think, each driver can add its on field After W4(i.e
> existing user_id) and introduce new field called match_offset in struct
> rte_regex_ops
>
> ie. struct rte_regex_match *matches == ops + ops-> match_offset; so that, Each
> driver can add enough driver specific metadata.
>
>
>
next prev parent reply other threads:[~2019-09-27 14:45 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-27 15:50 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 [this message]
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
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
2019-10-20 14:09 [dpdk-dev] [RFC PATCH v1] " Jerin Jacob Kollanukkaran
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=BYAPR18MB24242933C05C327077DCCCD8C8810@BYAPR18MB2424.namprd18.prod.outlook.com \
--to=jerinj@marvell.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=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).