On Sun, Mar 15, 2020 at 10:05:53AM +0000, Ori Kam wrote: Hi Ori, > Hi Xiang, > > > > -----Original Message----- > > From: Wang Xiang <[email protected]> > > Sent: Friday, March 13, 2020 3:20 AM > > To: Ori Kam <[email protected]> > > Cc: [email protected]; [email protected]; [email protected]; Shahaf > > Shuler <[email protected]>; [email protected]; Opher Reviv > > <[email protected]>; Alex Rosenbaum <[email protected]>; > > [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; > > [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; Thomas Monjalon > > <[email protected]> > > 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
