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

[Jerin Jacob Kollanukkaran]

> -----Original Message-----
> From: Shahaf Shuler <shahafs at mellanox.com>
> Sent: Wednesday, October 2, 2019 2:23 PM
> To: Jerin Jacob Kollanukkaran <jerinj at marvell.com>; Thomas Monjalon
> <thomas at monjalon.net>; 'dev at dpdk.org' <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'
> <yang.a.hong at intel.com>; 'harry.chang at intel.com' <harry.chang at intel.com>;
> 'gu.jian1 at zte.com.cn' <gu.jian1 at zte.com.cn>; 'shanjiangh at chinatelecom.cn'
> <shanjiangh at chinatelecom.cn>; 'zhangy.yun at chinatelecom.cn'
> <zhangy.yun at chinatelecom.cn>; 'lixingfu at huachentel.com'
> <lixingfu at huachentel.com>; 'wushuai at inspur.com' <wushuai at inspur.com>;
> 'yuyingxia at yxlink.com' <yuyingxia at yxlink.com>;
> 'fanchenggang at sunyainfo.com' <fanchenggang at sunyainfo.com>;
> 'davidfgao at tencent.com' <davidfgao at tencent.com>;
> 'liuzhong1 at chinaunicom.cn' <liuzhong1 at chinaunicom.cn>;
> 'zhaoyong11 at huawei.com' <zhaoyong11 at huawei.com>; 'oc at yunify.com'
> <oc at yunify.com>; 'jim at netgate.com' <jim at netgate.com>;
> 'hongjun.ni at intel.com' <hongjun.ni at intel.com>; 'j.bromhead at titan-ic.com'
> <j.bromhead at titan-ic.com>; 'deri at ntop.org' <deri at ntop.org>;
> 'fc at napatech.com' <fc at napatech.com>; 'arthur.su at lionic.com'
> <arthur.su at 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.




> 
> >