From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; Tue, 23 May 2017 11:50:52 +0200 (CEST) Received: by mail-wm0-f52.google.com with SMTP id d127so18732173wmf.0 for ; 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 To: "Zhao1, Wei" Cc: "dev@dpdk.org" , "Xing, Beilei" Message-ID: <20170523095045.GB1758@6wind.com> References: <3bbb1cac29fa37b713a7586a93291ddb9f91275a.1482168851.git.adrien.mazarguil@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 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 }. > But what I need is pattern[]={0x01, 0x23, 0x0 } 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