From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <wei.zhao1@intel.com>
Received: from mga05.intel.com (mga05.intel.com [192.55.52.43])
by dpdk.org (Postfix) with ESMTP id 384B77CAA
for <dev@dpdk.org>; Wed, 24 May 2017 10:46:38 +0200 (CEST)
Received: from orsmga004.jf.intel.com ([10.7.209.38])
by fmsmga105.fm.intel.com with ESMTP; 24 May 2017 01:46:37 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.38,385,1491289200"; d="scan'208";a="90944067"
Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86])
by orsmga004.jf.intel.com with ESMTP; 24 May 2017 01:46:36 -0700
Received: from pgsmsx103.gar.corp.intel.com ([169.254.2.243]) by
KMSMSX151.gar.corp.intel.com ([169.254.10.94]) with mapi id 14.03.0319.002;
Wed, 24 May 2017 16:46:35 +0800
From: "Zhao1, Wei" <wei.zhao1@intel.com>
To: Adrien Mazarguil <adrien.mazarguil@6wind.com>
CC: "dev@dpdk.org" <dev@dpdk.org>, "Xing, Beilei" <beilei.xing@intel.com>
Thread-Topic: [dpdk-dev] [PATCH v3 01/25] ethdev: introduce generic flow API
Thread-Index: AQHSWiBfMe5jxiyOQkC12oWHYr8YwqICWyfg//++lICAAaubYP//wAQAgACXz9A=
Date: Wed, 24 May 2017 08:46:34 +0000
Message-ID: <A2573D2ACFCADC41BB3BE09C6DE313CA07B7816C@PGSMSX103.gar.corp.intel.com>
References: <cover.1481903839.git.adrien.mazarguil@6wind.com>
<cover.1482168851.git.adrien.mazarguil@6wind.com>
<3bbb1cac29fa37b713a7586a93291ddb9f91275a.1482168851.git.adrien.mazarguil@6wind.com>
<A2573D2ACFCADC41BB3BE09C6DE313CA07B75E5D@PGSMSX103.gar.corp.intel.com>
<20170523095045.GB1758@6wind.com>
<A2573D2ACFCADC41BB3BE09C6DE313CA07B780A2@PGSMSX103.gar.corp.intel.com>
<20170524073212.GE1758@6wind.com>
In-Reply-To: <20170524073212.GE1758@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]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 24 May 2017 08:46:39 -0000
Hi, Adrien
> -----Original Message-----
> From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> Sent: Wednesday, May 24, 2017 3:32 PM
> To: Zhao1, Wei <wei.zhao1@intel.com>
> Cc: dev@dpdk.org; Xing, Beilei <beilei.xing@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v3 01/25] ethdev: introduce generic flow A=
PI
>=20
> On Wed, May 24, 2017 at 03:32:02AM +0000, Zhao1, Wei wrote:
> > Hi,
> >
> > > -----Original Message-----
> > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > > Sent: Tuesday, May 23, 2017 5:51 PM
> > > To: Zhao1, Wei <wei.zhao1@intel.com>
> > > Cc: dev@dpdk.org; Xing, Beilei <beilei.xing@intel.com>
> > > Subject: Re: [dpdk-dev] [PATCH v3 01/25] ethdev: introduce generic
> > > flow API
> > >
> > > 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 <repeats 126 times>=
}
> > >
> > > Similar limitation as I answered in [1] then. This is not a problem
> > > in the 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, fi=
lter.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 actions 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 plans.
> > >
> >
> > Thank you for your explanation. But there is some key point I want to
> repeat:
> > 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
> pattern is 0x0123 / end actions queue index 1 / end "
> > what I need is pattern[]=3D{0x01, 0x23, 0x0 <repeats 126 times>}.
> > not pattern[]=3D{ 0x00, 0x01, 0x02, 0x03, 0x0 <repeats 124 times> }.
> > And also, not pattern[]=3D{ 0x30, 0x31, 0x32, 0x33, 0x0 <repeats 124 t=
imes> }.
>=20
> Right, I misread your original pattern[] intent. You would get such a pat=
tern
> by specifying \x01\x23 (just like C string literals). It would even accep=
t octal
> notation "\01\043". Both would yield { 0x01, 0x23 }.
>=20
> Does something like that satisfy the requirements?
Yes, After the repeat, I think we both understand each other.
>=20
> > And this problem is not a block for code develop for 17.08, but it is n=
eeded
> for tester and user in the feature.
>=20
> Well, I've actually started implementing the above long ago in testpmd bu=
t
> didn't have time to clean up the patch and submit it yet (moreover it was=
not
> needed until now). If the idea works for your use case, I can attempt to =
do
> that soon.
>=20
All that decision is up to you, and I think it is great.
> > > > At least in the struct rte_flow_item_raw, the member pattern is
> > > > the same
> > > as old filter?
> > >
> > > It is the same as the old filter, except you cannot provide it in
> > > hexadecimal 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 RAW items, there's no such limitation.
> > >
> > > [1] http://dpdk.org/ml/archives/dev/2017-May/065798.html
> > >
> > > --
> > > Adrien Mazarguil
> > > 6WIND
>=20
> --
> Adrien Mazarguil
> 6WIND