From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <adrien.mazarguil@6wind.com>
Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52])
by dpdk.org (Postfix) with ESMTP id C2F872C16
for <dev@dpdk.org>; Tue, 23 May 2017 11:50:52 +0200 (CEST)
Received: by mail-wm0-f52.google.com with SMTP id d127so18732173wmf.0
for <dev@dpdk.org>; Tue, 23 May 2017 02:50:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=6wind-com.20150623.gappssmtp.com; s=20150623;
h=date:from:to:cc:subject:message-id:references:mime-version
:content-disposition:in-reply-to;
bh=7b8+unVtxHsxq9ovCaABrDwg0jUc5372hDp7IG4xo5A=;
b=P+CbmFObAGlK4F5/UDN7z7O3Gm1icR29Zn9o342UXi2s1djT2oqI4txKm7iSp+x0PH
hxWmDw6dZJi0utv58r7UYSpZPSoYIqepHlR5W9UyqhmYyeRFXZTKveus634VXB7EtABa
qbCKUn8xf3uCGRTIzTKlp7psx4yTrQqL1DrPK5VmWsYNxkn2GUu+PvM4aYokxQDeKIkq
lERG2zdrQU4w1Ks4Hc0Qo8Si/9G37WORJYdgT3eXq6xH2Q6QwjFFUcJd2NYYqA5xAxo9
54DcUygAIk6DW6fA1+FNGq8VTwde8/98XdGIxdMldPFaYKBi/29aCaZ18V9bTUP85voh
udWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:date:from:to:cc:subject:message-id:references
:mime-version:content-disposition:in-reply-to;
bh=7b8+unVtxHsxq9ovCaABrDwg0jUc5372hDp7IG4xo5A=;
b=t2uQyflTymUgxx+o5nkOaxIIy6xQJlqk4mZHKbztnv0t9vgjSMil0IugIm8kuOZ0rM
zDbB7Is0wWaxp9lJzx5ZWT7JLS49RrJDBZCypDd+mCvVqRIKUGAKBk5JoUs13uzqE/g6
E2nyw55YCE1kaVYThB355PM0QMiIiFtAHoJkG8XxCTnQmPAqfX13/Zb5A2v5Xy+qGZDm
PzRArZUwRiXDHUGTbqxrvnjLmJZs8lOe7FlT+7Lb2mbmfkTj0ygx9rR+BjBOOMjz3oP5
SJeCYUUGW/bzOJvY2kC0JlOc4j1ze7+yCd7HLNlhUM21GbW4cOgUmk1baYyDrGVfaR96
jgwA==
X-Gm-Message-State: AODbwcDkXBKqanU/zOUvuDRDZTMK8aGsX+pD13Ub+b/s5ifGp3gNhhFd
07Gq4y1Oe20dx3A3OLY=
X-Received: by 10.28.84.14 with SMTP id i14mr1654829wmb.81.1495533052429;
Tue, 23 May 2017 02:50:52 -0700 (PDT)
Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78])
by smtp.gmail.com with ESMTPSA id i11sm279108wrb.44.2017.05.23.02.50.51
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 23 May 2017 02:50:51 -0700 (PDT)
Date: Tue, 23 May 2017 11:50:45 +0200
From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
To: "Zhao1, Wei" <wei.zhao1@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, "Xing, Beilei" <beilei.xing@intel.com>
Message-ID: <20170523095045.GB1758@6wind.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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <A2573D2ACFCADC41BB3BE09C6DE313CA07B75E5D@PGSMSX103.gar.corp.intel.com>
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: Tue, 23 May 2017 09:50:53 -0000
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[]={ 0x30, 0x31, 0x32, 0x33, 0x0 <repeats 124 times> }.
> But what I need is pattern[]={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 = 0; i < len; i++) {
> c = bytes_ptr[i];
> if (isxdigit(c) == 0) {
> /* invalid characters. */
> printf("invalid input\n");
> return;
> }
> val = xdigit2val(c);
> if (i % 2) {
> byte |= val;
> filter.bytes[j] = byte;
> printf("bytes[%d]:%02x ", j, filter.bytes[j]);
> j++;
> byte = 0;
> } else
> byte |= 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 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.
> 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