> -----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]>; '[email protected]'
> <[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.
