DPDK patches and discussions
 help / color / mirror / Atom feed
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: Tue, 10 Sep 2019 11:02:46 +0000	[thread overview]
Message-ID: <BYAPR18MB2424E5D448C0D2DCD1ADD6D0C8B60@BYAPR18MB2424.namprd18.prod.outlook.com> (raw)
In-Reply-To: <AM0PR0502MB37956BA74063243F2C56EEDFC3AA0@AM0PR0502MB3795.eurprd05.prod.outlook.com>

> 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()


> > +
> > + */
> > +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.

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.





  parent reply	other threads:[~2019-09-10 11:03 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 [this message]
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
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=BYAPR18MB2424E5D448C0D2DCD1ADD6D0C8B60@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).