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 <[email protected]> > > Sent: Wednesday, October 2, 2019 11:23 AM > > To: Jerin Jacob Kollanukkaran <[email protected]>; Thomas Monjalon > > <[email protected]>; '[email protected]' <[email protected]> > > Cc: Pavan Nikhilesh Bhagavatula <[email protected]>; 'Hemant > > Agrawal' <[email protected]>; Opher Reviv > <[email protected]>; > > Alex Rosenbaum <[email protected]>; Dovrat Zifroni > > <[email protected]>; Prasun Kapoor <[email protected]>; 'Nipun > > Gupta' <[email protected]>; 'Wang, Xiang W' > > <[email protected]>; 'Richardson, Bruce' > <[email protected]>; '[email protected]' > > <[email protected]>; '[email protected]' > > <[email protected]>; '[email protected]' <[email protected]>; > '[email protected]' > > <[email protected]>; '[email protected]' > > <[email protected]>; '[email protected]' > > <[email protected]>; '[email protected]' > <[email protected]>; > > '[email protected]' <[email protected]>; > > '[email protected]' <[email protected]>; > > '[email protected]' <[email protected]>; > > '[email protected]' <[email protected]>; > > '[email protected]' <[email protected]>; '[email protected]' > > <[email protected]>; '[email protected]' <[email protected]>; > > '[email protected]' <[email protected]>; 'j.bromhead@titan- > ic.com' > > <[email protected]>; '[email protected]' <[email protected]>; > > '[email protected]' <[email protected]>; '[email protected]' > > <[email protected]> > > 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. >
