> -----Original Message----- > From: Shahaf Shuler <shah...@mellanox.com> > Sent: Wednesday, October 2, 2019 2:23 PM > To: Jerin Jacob Kollanukkaran <jer...@marvell.com>; Thomas Monjalon > <tho...@monjalon.net>; 'dev@dpdk.org' <dev@dpdk.org> > Cc: Pavan Nikhilesh Bhagavatula <pbhagavat...@marvell.com>; 'Hemant > Agrawal' <hemant.agra...@nxp.com>; Opher Reviv <op...@mellanox.com>; > Alex Rosenbaum <al...@mellanox.com>; Dovrat Zifroni > <dov...@marvell.com>; Prasun Kapoor <pkap...@marvell.com>; 'Nipun > Gupta' <nipun.gu...@nxp.com>; 'Wang, Xiang W' <xiang.w.w...@intel.com>; > 'Richardson, Bruce' <bruce.richard...@intel.com>; 'yang.a.h...@intel.com' > <yang.a.h...@intel.com>; 'harry.ch...@intel.com' <harry.ch...@intel.com>; > 'gu.ji...@zte.com.cn' <gu.ji...@zte.com.cn>; 'shanjia...@chinatelecom.cn' > <shanjia...@chinatelecom.cn>; 'zhangy....@chinatelecom.cn' > <zhangy....@chinatelecom.cn>; 'lixin...@huachentel.com' > <lixin...@huachentel.com>; 'wush...@inspur.com' <wush...@inspur.com>; > 'yuying...@yxlink.com' <yuying...@yxlink.com>; > 'fanchengg...@sunyainfo.com' <fanchengg...@sunyainfo.com>; > 'davidf...@tencent.com' <davidf...@tencent.com>; > 'liuzho...@chinaunicom.cn' <liuzho...@chinaunicom.cn>; > 'zhaoyon...@huawei.com' <zhaoyon...@huawei.com>; 'o...@yunify.com' > <o...@yunify.com>; 'j...@netgate.com' <j...@netgate.com>; > 'hongjun...@intel.com' <hongjun...@intel.com>; 'j.bromh...@titan-ic.com' > <j.bromh...@titan-ic.com>; 'd...@ntop.org' <d...@ntop.org>; > 'f...@napatech.com' <f...@napatech.com>; 'arthur...@lionic.com' > <arthur...@lionic.com> > 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. > > >
