From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id AEB2CA0559; Mon, 16 Mar 2020 02:25:20 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C61B24CA6; Mon, 16 Mar 2020 02:25:19 +0100 (CET) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 240251AFF for ; Mon, 16 Mar 2020 02:25:17 +0100 (CET) IronPort-SDR: eQJsE8CuCJaTrlZ1ScMaQagT5BsFDrwulRz0tmvXXb6EtLVGtqVMthL0XYKHcmn56GldjO2zLt owQwg6QNFauQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2020 18:25:16 -0700 IronPort-SDR: EgrDIxv1LXI67djx5cgsMqtnj591abFW16SUrJp40/aR7NuahD66KezFz1YGzaD+qA4wpVS0xC 3Fj/xbie7zHQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,558,1574150400"; d="scan'208";a="235885850" Received: from hyperscan.sh.intel.com (HELO hyperscan) ([10.67.104.81]) by fmsmga007.fm.intel.com with ESMTP; 15 Mar 2020 18:25:09 -0700 Date: Mon, 16 Mar 2020 09:25:42 +0800 From: Wang Xiang To: Ori Kam Cc: "jerinj@marvell.com" , "dev@dpdk.org" , "pbhagavatula@marvell.com" , Shahaf Shuler , "hemant.agrawal@nxp.com" , Opher Reviv , Alex Rosenbaum , "dovrat@marvell.com" , "pkapoor@marvell.com" , "nipun.gupta@nxp.com" , "bruce.richardson@intel.com" , "yang.a.hong@intel.com" , "harry.chang@intel.com" , "gu.jian1@zte.com.cn" , "shanjiangh@chinatelecom.cn" , "zhangy.yun@chinatelecom.cn" , "lixingfu@huachentel.com" , "wushuai@inspur.com" , "yuyingxia@yxlink.com" , "fanchenggang@sunyainfo.com" , "davidfgao@tencent.com" , "liuzhong1@chinaunicom.cn" , "zhaoyong11@huawei.com" , "oc@yunify.com" , "jim@netgate.com" , "hongjun.ni@intel.com" , "j.bromhead@titan-ic.com" , "deri@ntop.org" , "fc@napatech.com" , "arthur.su@lionic.com" , Thomas Monjalon Message-ID: <20200316012542.GB25215@hyperscan> References: <20190627155036.56940-1-jerinj@marvell.com> <1583836353-42867-1-git-send-email-orika@mellanox.com> <20200313012027.GA25215@hyperscan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Subject: Re: [dpdk-dev] [RFC v6] regexdev: introduce regexdev subsystem X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Sun, Mar 15, 2020 at 10:05:53AM +0000, Ori Kam wrote: Hi Ori, > Hi Xiang, > > > > -----Original Message----- > > From: Wang Xiang > > Sent: Friday, March 13, 2020 3:20 AM > > To: Ori Kam > > Cc: jerinj@marvell.com; dev@dpdk.org; pbhagavatula@marvell.com; Shahaf > > Shuler ; hemant.agrawal@nxp.com; Opher Reviv > > ; Alex Rosenbaum ; > > dovrat@marvell.com; pkapoor@marvell.com; nipun.gupta@nxp.com; > > bruce.richardson@intel.com; yang.a.hong@intel.com; harry.chang@intel.com; > > gu.jian1@zte.com.cn; shanjiangh@chinatelecom.cn; > > zhangy.yun@chinatelecom.cn; lixingfu@huachentel.com; wushuai@inspur.com; > > yuyingxia@yxlink.com; fanchenggang@sunyainfo.com; > > davidfgao@tencent.com; liuzhong1@chinaunicom.cn; > > zhaoyong11@huawei.com; oc@yunify.com; jim@netgate.com; > > hongjun.ni@intel.com; j.bromhead@titan-ic.com; deri@ntop.org; > > fc@napatech.com; arthur.su@lionic.com; Thomas Monjalon > > > > 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