On Sun, Mar 15, 2020 at 10:05:53AM +0000, Ori Kam wrote: Hi Ori, > 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 > 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
