[dpdk-dev] [RFC PATCH v1] regexdev: introduce regexdev subsystem

[Jerin Jacob Kollanukkaran]

> -----Original Message-----
> From: Shahaf Shuler <shahafs at mellanox.com>
> Sent: Wednesday, October 2, 2019 11:23 AM
> To: Jerin Jacob Kollanukkaran <jerinj at marvell.com>; Thomas Monjalon
> <thomas at monjalon.net>; 'dev at dpdk.org' <dev at dpdk.org>
> Cc: Pavan Nikhilesh Bhagavatula <pbhagavatula at marvell.com>; 'Hemant
> Agrawal' <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' <nipun.gupta at nxp.com>; 'Wang, Xiang W' <xiang.w.wang at intel.com>;
> 'Richardson, Bruce' <bruce.richardson at intel.com>; 'yang.a.hong at intel.com'
> <yang.a.hong at intel.com>; 'harry.chang at intel.com' <harry.chang at intel.com>;
> 'gu.jian1 at zte.com.cn' <gu.jian1 at zte.com.cn>; 'shanjiangh at chinatelecom.cn'
> <shanjiangh at chinatelecom.cn>; 'zhangy.yun at chinatelecom.cn'
> <zhangy.yun at chinatelecom.cn>; 'lixingfu at huachentel.com'
> <lixingfu at huachentel.com>; 'wushuai at inspur.com' <wushuai at inspur.com>;
> 'yuyingxia at yxlink.com' <yuyingxia at yxlink.com>;
> 'fanchenggang at sunyainfo.com' <fanchenggang at sunyainfo.com>;
> 'davidfgao at tencent.com' <davidfgao at tencent.com>;
> 'liuzhong1 at chinaunicom.cn' <liuzhong1 at chinaunicom.cn>;
> 'zhaoyong11 at huawei.com' <zhaoyong11 at huawei.com>; 'oc at yunify.com'
> <oc at yunify.com>; 'jim at netgate.com' <jim at netgate.com>;
> 'hongjun.ni at intel.com' <hongjun.ni at intel.com>; 'j.bromhead at titan-ic.com'
> <j.bromhead at titan-ic.com>; 'deri at ntop.org' <deri at ntop.org>;
> 'fc at napatech.com' <fc at napatech.com>; 'arthur.su at lionic.com'
> <arthur.su at lionic.com>
> Subject: RE: [dpdk-dev] [RFC PATCH v1] regexdev: introduce regexdev
> subsystem
> 
> > > > 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?
> 
> IMO we should have two separate functions - one to only compile. One to only
> update.
> 
> So I would prefer #1, with addition (if not already present) of API to update
> rules.


OK. Will change it in next version.


> 
> >
> >
> > >
> > >
> > > > > +
> > > > > + */
> > > > > +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.
> 
> Application writes to the field. Device reads from this fields.
> Unlike the user_ptr which is complete opaque to the device, connection_id field
> will have some meaning (e.g. DPI rules can apply on it).

Will you be connecting the value to rte_flow etc to get the complete data flow.
I understand applications writes to this field, But I am not sure what values 
Needs to be written and how it will be connected in overall scheme of things.
I am not sure even what to write doxgygen comment for this field.

Can we add this field once we have the complete data flow?. Since it is
Experimental we can always add new field.