> -----Original Message----- > From: Shahaf Shuler <[email protected]> > Sent: Wednesday, October 2, 2019 2:23 PM > 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 > > > > > > > > > > > > > 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.
Yes. DPI inline support is a valid use case. We can add that support when data flow is clear and HW support is available. > > >
