[dpdk-dev] [RFC v6] regexdev: introduce regexdev subsystem

[Wang Xiang]

On Sun, Mar 15, 2020 at 10:05:53AM +0000, Ori Kam wrote:
Hi Ori,

> Hi Xiang,
> 
> 
> > -----Original Message-----
> > From: Wang Xiang <xiang.w.wang at intel.com>
> > Sent: Friday, March 13, 2020 3:20 AM
> > To: Ori Kam <orika at mellanox.com>
> > Cc: jerinj at marvell.com; dev at dpdk.org; pbhagavatula at marvell.com; Shahaf
> > Shuler <shahafs at mellanox.com>; hemant.agrawal at nxp.com; Opher Reviv
> > <opher at mellanox.com>; Alex Rosenbaum <alexr at mellanox.com>;
> > dovrat at marvell.com; pkapoor at marvell.com; nipun.gupta at nxp.com;
> > bruce.richardson at intel.com; yang.a.hong at intel.com; harry.chang at intel.com;
> > gu.jian1 at zte.com.cn; shanjiangh at chinatelecom.cn;
> > zhangy.yun at chinatelecom.cn; lixingfu at huachentel.com; wushuai at inspur.com;
> > yuyingxia at yxlink.com; fanchenggang at sunyainfo.com;
> > davidfgao at tencent.com; liuzhong1 at chinaunicom.cn;
> > zhaoyong11 at huawei.com; oc at yunify.com; jim at netgate.com;
> > hongjun.ni at intel.com; j.bromhead at titan-ic.com; deri at ntop.org;
> > fc at napatech.com; arthur.su at lionic.com; Thomas Monjalon
> > <thomas at monjalon.net>
> > Subject: Re: [RFC v6] regexdev: introduce regexdev subsystem
> > 
> > Hi Ori,
> > 
> > Sorry for the late response as I am occupied by other works.
> > Two comments below to make the definitions compatible to Hyperscan.
> > 
> > Thanks,
> > Xiang
> > 
> > On Tue, Mar 10, 2020 at 10:32:33AM +0000, Ori Kam wrote:
> > > +#define RTE_REGEX_PCRE_RULE_MATCH_ALL_F (1ULL << 13)
> > > +/**< This flag marks that the results for the pattern that is being compiled
> > > + * should include all possible matches.
> > > + * @see struct rte_regex_dev_info::rule_flags, struct
> > rte_regex_rule::rule_flags
> > > + */
> > > +
> > Can we change this flag to RTE_REGEX_DEV_CFG_MATCH_ALL since Hyperscan
> > only supports
> > match all mode and users don't have to specify this flag per rule?
> >
> 
> Sure, we can replace the RTE_REGEX_PCRE_RULE_MATCH_ALL_F with 
> RTE_REGEX_DEV_CFG_MATCH_ALL, and add RTE_REGEX_DEV_CAPA_SUPP_MATCH_ALL
>
Ack, thanks. 
>  
> > > + */
> > > +__rte_experimental
> > > +int
> > > +rte_regex_dev_info_get(uint8_t dev_id, struct rte_regex_dev_info
> > *dev_info);
> > > +
> > > +/* Enumerates RegEx device configuration flags */
> > > +#define RTE_REGEX_DEV_CFG_CROSS_BUFFER_SCAN_F (1ULL << 0)
> > > +/**< Cross buffer scan refers to the ability to be able to detect
> > > + * matches that occur across buffer boundaries, where the buffers are
> > related
> > > + * to each other in some way. Enable this flag when to scan payload size
> > > + * greater than struct rte_regex_dev_info::max_payload_size and/or
> > > + * matches can present across scan buffer boundaries.
> > > + *
> > > + * @see struct rte_regex_dev_info::max_payload_size
> > > + * @see struct rte_regex_dev_config::dev_cfg_flags,
> > rte_regex_dev_configure()
> > > + * @see RTE_REGEX_OPS_RSP_PMI_SOJ_F
> > > + * @see RTE_REGEX_OPS_RSP_PMI_EOJ_F
> > > + * @see RTE_REGEX_OPS_RSP_PMI_TOJ_F
> > > + */
> > > +
> > Can we add another flag
> > RTE_REGEX_DEV_CFG_CROSS_BUFFER_SCAN_FULL_F? In this case,
> > we only return full match for cross buffer scan without any partial result and
> > without returning response flags such as RTE_REGEX_OPS_RSP_PMI_*.
> 
> I think that it is good in any case to return a flag if the detection was based on 
> more than one buffer.
> So I don't really see the advantage of adding such a flag.
> As far as I understand in your case if the match started in previous buffer and ended 
> in the current buffer then you will return also the flag of RTE_REGEX_OPS_RSP_PMI_TOJ_F
> For my general knowledge, in your system if we have the following regex: ABC
> In the first buffer we have xxxA size 4 and the second buffer is BCxx
> If I understand correctly for first buffer you will return no match found.
> For the second buffer you will return found and end offset will be equal to  2
> Am I correct?
> Or you are going to return end offset 6 because it started from the previous buffer? 
> 
Hyperscan guarantees the same matching result regardless of the data is in a single
block or scattered to multiple blocks. So we'll return end offset 6 in this case
without giving any flag indicating whether the match is started in previous buffer
or current buffer. 
> 
> Best,
> Ori
> 

Best,
Xiang