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

[Shahaf Shuler <shahafs@mellanox.com>]

Wednesday, October 2, 2019 11:32 AM, Jerin Jacob Kollanukkaran:
> Subject: Re: [dpdk-dev] [RFC PATCH v1] regexdev: introduce regexdev
> subsystem
> 
> > -----Original Message-----
> > From: Shahaf Shuler <shahafs@mellanox.com>
> > Sent: Wednesday, October 2, 2019 11:23 AM
> > To: Jerin Jacob Kollanukkaran <jerinj@marvell.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
> >
> > > > > 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.

Yes. We can revisit it later, so long we agree that such field can be added. 

>