From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 35CAB3798 for ; Wed, 24 May 2017 05:39:47 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 May 2017 20:39:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,384,1491289200"; d="scan'208,217";a="91050454" Received: from kmsmsx155.gar.corp.intel.com ([172.21.73.106]) by orsmga002.jf.intel.com with ESMTP; 23 May 2017 20:39:44 -0700 Received: from pgsmsx103.gar.corp.intel.com ([169.254.2.243]) by KMSMSX155.gar.corp.intel.com ([169.254.15.30]) with mapi id 14.03.0319.002; Wed, 24 May 2017 11:32:03 +0800 From: "Zhao1, Wei" To: Adrien Mazarguil CC: "dev@dpdk.org" , "Xing, Beilei" Thread-Topic: [dpdk-dev] [PATCH v3 01/25] ethdev: introduce generic flow API Thread-Index: AQHSWiBfMe5jxiyOQkC12oWHYr8YwqICWyfg//++lICAAaubYA== Date: Wed, 24 May 2017 03:32:02 +0000 Message-ID: References: <3bbb1cac29fa37b713a7586a93291ddb9f91275a.1482168851.git.adrien.mazarguil@6wind.com> <20170523095045.GB1758@6wind.com> In-Reply-To: <20170523095045.GB1758@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.20.205] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v3 01/25] ethdev: introduce generic flow API 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: , X-List-Received-Date: Wed, 24 May 2017 03:39:49 -0000 Hi, > -----Original Message----- > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > Sent: Tuesday, May 23, 2017 5:51 PM > To: Zhao1, Wei > Cc: dev@dpdk.org; Xing, Beilei > Subject: Re: [dpdk-dev] [PATCH v3 01/25] ethdev: introduce generic flow A= PI > > Hi Wei, > > On Tue, May 23, 2017 at 06:07:20AM +0000, Zhao1, Wei wrote: > > Hi, Adrien > > > > > +struct rte_flow_item_raw { > > > + uint32_t relative:1; /**< Look for pattern after the previous item.= */ > > > + uint32_t search:1; /**< Search pattern from offset (see also limit)= . */ > > > + uint32_t reserved:30; /**< Reserved, must be set to zero. */ > > > + int32_t offset; /**< Absolute or relative offset for pattern. */ > > > + uint16_t limit; /**< Search area limit for start of pattern. */ > > > + uint16_t length; /**< Pattern length. */ > > > + uint8_t pattern[]; /**< Byte string to look for. */ }; > > > > When I use this API to test igb flex filter, I find that in the struct > > rte_flow_item_raw, the member pattern is not the same as my purpose. > > For example, If I type in " flow create 0 ingress pattern raw relative= is 0 > pattern is 0123 / end actions queue index 1 / end " > > What I get in NIC layer is pattern[]=3D{ 0x30, 0x31, 0x32, 0x33, 0x0 <= repeats > 124 times> }. > > But what I need is pattern[]=3D{0x01, 0x23, 0x0 } > > Similar limitation as I answered in [1] then. This is not a problem in th= e > rte_flow API, it's only that the testpmd parser currently provides > unprocessed strings to the PMD, and there is currently no method to work > around that. > > > About the format change of flex_filter, I have reference to the > > testpmd function cmd_flex_filter_parsed(), There is details of format > change from ASIC code to data, for example: > > > > for (i =3D 0; i < len; i++) { > > c =3D bytes_ptr[i]; > > if (isxdigit(c) =3D=3D 0) { > > /* invalid characters. */ > > printf("invalid input\n"); > > return; > > } > > val =3D xdigit2val(c); > > if (i % 2) { > > byte |=3D val; > > filter.bytes[j] =3D byte; > > printf("bytes[%d]:%02x ", j, filter= .bytes[j]); > > j++; > > byte =3D 0; > > } else > > byte |=3D val << 4; > > } > > > > and there is also usage example in the DPDK document testpmd_app_ug- > 16.11.pdf: > > (it also not use ASIC code) > > > > testpmd> flex_filter 0 add len 16 bytes > > testpmd> 0x00000000000000000000000008060000 \ > > mask 000C priority 3 queue 3 > > I understand, the difference between both commands is only that unlike > flex_filter, flow does not interpret the provided string as hexadecimal. > > > so, will our new generic flow API align to the old format in flex byte = filter in > 17.08 or in the future? > > What I have in mind instead is a printf-like input method. Using the rule= you > provided above: > > flow create 0 ingress pattern raw relative is 0 pattern is 0123 / end a= ctions > queue index 1 / end > > Will always yield "0123", however: > > flow create 0 ingress pattern raw relative is 0 pattern is \x00\x01\x02\= x03 / > end actions queue index 1 / end > > Will yield the intended pattern. Currently this format is interpreted as = is > (you'll get "\x00\x01\x02\x03") however escape interpretation is in the p= lans. > Thank you for your explanation. But there is some key point I want to repea= t: For example, If I type in " flow create 0 ingress pattern raw relative is = 0 pattern is 0123 / end actions queue index 1 / end " Or maybe more accurate, " flow create 0 ingress pattern raw relative is 0 p= attern is 0x0123 / end actions queue index 1 / end " what I need is pattern[]=3D{0x01, 0x23, 0x0 }. not pattern[]=3D{ 0x00, 0x01, 0x02, 0x03, 0x0 }. And also, not pattern[]=3D{ 0x30, 0x31, 0x32, 0x33, 0x0 }. And this problem is not a block for code develop for 17.08, but it is neede= d for tester and user in the feature. > > At least in the struct rte_flow_item_raw, the member pattern is the sa= me > as old filter? > > It is the same as the old filter, except you cannot provide it in hexadec= imal > format yet. No changes needed on the PMD side in any case. > > Again, this is only a testpmd implementation issue, that doesn't prevent > developers from creating programs that directly provide binary data to RA= W > items, there's no such limitation. > > [1] http://dpdk.org/ml/archives/dev/2017-May/065798.html > > -- > Adrien Mazarguil > 6WIND