Hi Xiang,
> -----Original Message----- > From: Wang Xiang <xiang.w.w...@intel.com> > Sent: Friday, March 13, 2020 3:20 AM > To: Ori Kam <or...@mellanox.com> > Cc: jer...@marvell.com; dev@dpdk.org; pbhagavat...@marvell.com; Shahaf > Shuler <shah...@mellanox.com>; hemant.agra...@nxp.com; Opher Reviv > <op...@mellanox.com>; Alex Rosenbaum <al...@mellanox.com>; > dov...@marvell.com; pkap...@marvell.com; nipun.gu...@nxp.com; > bruce.richard...@intel.com; yang.a.h...@intel.com; harry.ch...@intel.com; > gu.ji...@zte.com.cn; shanjia...@chinatelecom.cn; > zhangy....@chinatelecom.cn; lixin...@huachentel.com; wush...@inspur.com; > yuying...@yxlink.com; fanchengg...@sunyainfo.com; > davidf...@tencent.com; liuzho...@chinaunicom.cn; > zhaoyon...@huawei.com; o...@yunify.com; j...@netgate.com; > hongjun...@intel.com; j.bromh...@titan-ic.com; d...@ntop.org; > f...@napatech.com; arthur...@lionic.com; Thomas Monjalon > <tho...@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 > > + */ > > +__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? Best, Ori
