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

[Shahaf Shuler]

Friday, September 27, 2019 5:46 PM, Jerin Jacob Kollanukkaran:
> subsystem
> 
> > -----Original Message-----
> > From: Jerin Jacob Kollanukkaran
> > Sent: Tuesday, September 10, 2019 4:33 PM
> > To: Shahaf Shuler <shahafs at mellanox.com>; Thomas Monjalon
> > <thomas at monjalon.net>; 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;
> > harry.chang at intel.com; gu.jian1 at zte.com.cn;
> > shanjiangh at chinatelecom.cn; zhangy.yun at chinatelecom.cn;
> > lixingfu at huachentel.com; wushuai at inspur.com; yuyingxia at yxlink.com;
> > fanchenggang at sunyainfo.com; davidfgao at tencent.com;
> > liuzhong1 at chinaunicom.cn; zhaoyong11 at huawei.com; oc at yunify.com;
> > jim at netgate.com; hongjun.ni at intel.com; j.bromhead at titan-ic.com;
> > deri at ntop.org; fc at napatech.com; arthur.su at lionic.com
> > Subject: RE: [dpdk-dev] [RFC PATCH v1] regexdev: introduce regexdev
> > subsystem
> >
> > > Hi Jerin,
> >
> > Hi Shahaf,
> >
> > > > + *
> > > > + * @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?

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. 

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

> 
> @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.
> >
> >
> >