From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 7BA2B548B for ; Wed, 24 May 2017 09:32:19 +0200 (CEST) Received: by mail-wm0-f43.google.com with SMTP id 7so52739505wmo.1 for ; Wed, 24 May 2017 00:32:19 -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=V4AFoeMAEbEBFlTDBQzxkN8gOfrjd0aF22dm13eNLDU=; b=rahgOvuRUJSN4gDePIE164OTdtFhmUisIhrkmXYbz7I6aN+2IGZG5m6Z4SMGnOj38x gDhRH9urVc4GbXs5ILanREIZ6ZdwFhiaBJy4HVFGjThwzU+A6GHT/u/otI4gVowjX0gU QvvbalXq0y7JXEz5DLgFMCHEizT2o2+lm19uVmnm8up9IEPsfaofGKM+wKbCJG1mRpYg j+tzfQGa0gEv8XPSfkFKf6AaVQN5mFWxW2FZpxym6FgUey1gJm+GR5hnXw7651O4svOA 5uoFCif5VXsfgnEbhwxcDgz2Vhf89XG5Yh5RezeWDqbsIbLe3pB+R/mJAlR5gxAXFU8n b8yQ== 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=V4AFoeMAEbEBFlTDBQzxkN8gOfrjd0aF22dm13eNLDU=; b=jIBBDt/z+wegnVp3eeEE3dF9q5k7+Uqa0CztIUzWS06hNl0InlA8elObjdTuG093G1 IWwpWIU7ZVTzwFMTnyELU8vochj0QrDSp6SWU8/QpDc5pLJP66KSQ00+vMwr7zksimK4 OSWrjoaTPEWk+1gBp/eoQ7AMT+NJWw385c43d1tW5wg84rITkHfJ1mra6G2LBTHusiz8 JOCBPyCQUIGMu/hcJ5zZAo1h7XTctECKW8gcY4rdRxLaxAJ2EFvD3jrQDguNlGm1uSqV FbuL0RDSKip085idFsm6gPLMMHGWBADpkA0ZJVk2Ud0ZRyNTO2dXBBobYZN1LbJoA3L/ H+mA== X-Gm-Message-State: AODbwcCv0x1+RN4ryHc3RvqCBVx/OCZqzuo8nHGuQvI48nQEsFPG7o/v o3QFtxkdeR2riaWK X-Received: by 10.28.147.9 with SMTP id v9mr5351610wmd.80.1495611139069; Wed, 24 May 2017 00:32:19 -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 s5sm2629523wra.60.2017.05.24.00.32.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 May 2017 00:32:17 -0700 (PDT) Date: Wed, 24 May 2017 09:32:12 +0200 From: Adrien Mazarguil To: "Zhao1, Wei" Cc: "dev@dpdk.org" , "Xing, Beilei" Message-ID: <20170524073212.GE1758@6wind.com> References: <3bbb1cac29fa37b713a7586a93291ddb9f91275a.1482168851.git.adrien.mazarguil@6wind.com> <20170523095045.GB1758@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: Wed, 24 May 2017 07:32:19 -0000 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 > > Cc: dev@dpdk.org; Xing, Beilei > > 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[]={ 0x30, 0x31, 0x32, 0x33, 0x0 > 124 times> }. > > > 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 > > > 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[]={0x01, 0x23, 0x0 }. > not pattern[]={ 0x00, 0x01, 0x02, 0x03, 0x0 }. > And also, not pattern[]={ 0x30, 0x31, 0x32, 0x33, 0x0 }. Right, I misread your original pattern[] intent. You would get such a pattern by specifying \x01\x23 (just like C string literals). It would even accept octal notation "\01\043". Both would yield { 0x01, 0x23 }. Does something like that satisfy the requirements? > And this problem is not a block for code develop for 17.08, but it is needed for tester and user in the feature. Well, I've actually started implementing the above long ago in testpmd but 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. > > > 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 -- Adrien Mazarguil 6WIND