From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 86E14A00E6 for ; Thu, 16 May 2019 08:00:36 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 18B724CAB; Thu, 16 May 2019 08:00:35 +0200 (CEST) Received: from smtp-3.sys.kth.se (smtp-3.sys.kth.se [130.237.48.192]) by dpdk.org (Postfix) with ESMTP id A0F35397D for ; Thu, 16 May 2019 08:00:33 +0200 (CEST) Received: from smtp-3.sys.kth.se (localhost.localdomain [127.0.0.1]) by smtp-3.sys.kth.se (Postfix) with ESMTP id 5A8D35747; Thu, 16 May 2019 08:00:33 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-3.sys.kth.se ([127.0.0.1]) by smtp-3.sys.kth.se (smtp-3.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UfZlKMWVnH7c; Thu, 16 May 2019 08:00:32 +0200 (CEST) X-KTH-Auth: barbette [83.249.19.162] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kth.se; s=default; t=1557986432; bh=cHaEj+o+uVnAMMjvW1QHHH+j1RMkkwcjJdydq0D3WLo=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=hk40dbQ6TmCxnVH+zYuKtWPsG9ZxBP6Gi8A6KMo9oZwSVMWZL/+zPKB4oYuZW5upX eu+9KYaKLCf90ScnVnHTePO6BFDA3EzhYa8hiCAmkl7lzlsTmMjZmbmQOLrg1fA9UB FbhOuWVxHJ2YjRdAaCmnxQAoGILMo6zziOnJT2hE= X-KTH-mail-from: barbette@kth.se Received: from [192.168.0.59] (c83-249-19-162.bredband.comhem.se [83.249.19.162]) by smtp-3.sys.kth.se (Postfix) with ESMTPSA id 360CB33CA; Thu, 16 May 2019 08:00:31 +0200 (CEST) To: =?UTF-8?B?5pu+5oe35oGp?= , Adrien Mazarguil Cc: Wenzhuo Lu , Konstantin Ananyev , =?UTF-8?B?5by15pWs5piK?= , users@dpdk.org References: <859A28C4-16C1-4397-9326-A3BEDB1AD73E@csie.io> <20190509123833.GF4284@6wind.com> <20190510134427.GG4284@6wind.com> <34F3ED03-F004-4172-9536-6CAAEE56A480@csie.io> <20190513084911.GI4284@6wind.com> <728B50C7-F3D8-4D9D-B569-66F29EB5D427@csie.io> From: Tom Barbette Message-ID: <751e597b-bfbe-5e4d-d138-f388ffd3eab7@kth.se> Date: Thu, 16 May 2019 08:00:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <728B50C7-F3D8-4D9D-B569-66F29EB5D427@csie.io> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-users] Flow director struct rte_flow_item_raw guild X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Sender: "users" Hi, I learned to look at the datasheet first, or look at the code before using "fancy" patterns (specially for Mellanox products that have no datasheet :p). Another way is to just try testpmd "flow create ..." quickly and see how it goes. Eg, for x520, you will have only access to what is called the 2 flex bytes, see the 82599 datasheet. If you grep the code you'll see the constraint are quite huge : It will fail if any of these is true : Mask : raw_mask->pattern[0] != 0xff || raw_mask->pattern[1] != 0xff) --> It's a fixed value search on two bytes. And you'll have to set that value for all patterns if I remember the datasheet correctly. Value: raw_spec->relative != 0 || raw_spec->search != 0 || raw_spec->reserved != 0 || raw_spec->offset > IXGBE_MAX_FLX_SOURCE_OFF || raw_spec->offset % 2 || raw_spec->limit != 0 || raw_spec->length != 2 || /* pattern can't be 0xffff */ (raw_spec->pattern[0] == 0xff && raw_spec->pattern[1] == 0xff)) I think XL710 (i40e) will be as restrained. From what I remember the flex bytes became a flex payload bytes. So you can't even match on the header. Tom For relevance, other mask stuff : raw_mask->relative != 0x1 || raw_mask->search != 0x1 || raw_mask->reserved != 0x0 || (uint32_t)raw_mask->offset != 0xffffffff || raw_mask->limit != 0xffff || raw_mask->length != 0xffff Le 16/05/2019 à 07:34, 曾懷恩 a écrit : > Hi Adrien, > > Thanks for reply, > > I tried to trace the mlx5 and ixgbe driver source code in DPDK source and notice that the flow director APIs are processed in it. > > I also compared the difference of flow director APIs between both two drivers and found that there is no rte_flow_item_raw defined in mlx5 driver. > > Is there any possible mlx5 series NICs support rte_flow_item_raw in the future? > > Thanks a lot. > > Best Regards, > >> Adrien Mazarguil 於 2019年5月13日 下午4:49 寫道： >> >> On Sat, May 11, 2019 at 02:20:48AM +0800, Huai-En Tseng wrote: >>> Thanks for reply, >>> >>> Actually I’d like to use rte_flow_item_raw structure with PPP header, the ICMP format is my little trial. >> >> OK, makes sense, there's no pattern item for PPP yet. >> >>> I will try X520 next week. >>> >>> Another question, is ixgbevf also support RTE_FLOW_ITEM_RAW? >> >> The ixgbe driver looks like it does but I'm not sure regarding the VF >> variant, Cc'ing maintainers just in case. >> >> -- >> Adrien Mazarguil >> 6WIND >