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 624F3A05D3 for ; Wed, 22 May 2019 05:19:04 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B549925A1; Wed, 22 May 2019 05:19:03 +0200 (CEST) Received: from mail-pl1-f194.google.com (mail-pl1-f194.google.com [209.85.214.194]) by dpdk.org (Postfix) with ESMTP id 722D71D7 for ; Wed, 22 May 2019 05:19:02 +0200 (CEST) Received: by mail-pl1-f194.google.com with SMTP id w7so345524plz.1 for ; Tue, 21 May 2019 20:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=csie-io.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=qvbiXt2plCC2/n7SlCPpZ2hdeWSETFl507xkNgTGnGU=; b=muz5auoeKELEUkVGqXaoZXl0SjOpjIOTiq704N8zvJS9SiqbTaf+e1cnr9Ryx74DcA HETh0LmYWcigaKN8ad0vLnQTk3wLR+EaJTbmhkTFNum1qhaRI6U2BKbSnByPOGeyM7Dq D1ggegvIYoJ6CBfds+PmLObwN/Rk1uD03pLAneRr4HeiL6YokMfIA6PgEumdsQDBE02W 4WD+w1p4/DmNitmH31GEXYgg44NwAX/rL7VNIhnCyOxLI4eGH5AcyInYkbU5r5PpIAKc r4WjFRfC4r228yqcVmoRvtmf3IOnxkxuG0q/JQxDX3j9zV1snMqCrLq482N9CdZ6fQzr IlOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=qvbiXt2plCC2/n7SlCPpZ2hdeWSETFl507xkNgTGnGU=; b=ggP2lemu1AeZSIIOD1RVIsRYtXDsRoelkxqUayzXpZ8d2lKBHiIhA02ty1oNxyTJuE 4yATlnWxMwbdE1w/FUTAL5mykKyV1bBrWyvq1Af7BIMJVynz+e5kmRkmUn/R0AS/WRTe 4yMPHDXLWCeZXxXOQthqhI4TmEj2XakfKXIl8l5u1twzVTGu6W1+pZlC7xlrarxtMTPp dvbaH5Pd+n+N22ldLdF1/l+idkYaOTpjiwtUkpMWBtutgEFmlwzuzjxTqg+gls+DgSJV /2jn2nbUAowNUgWUq5AxoibaikCEpSXHkcYqMxo6xZCo+jp3RmVJ1zKvKgUFetIiHzSS EZPg== X-Gm-Message-State: APjAAAUTJOwbY1FxepWY6QvTmvAT5S6UbHZZxB19jCVjE7KE7LmRBKS5 og6LVHc4L3iVE2ApRGVahtwiJA== X-Google-Smtp-Source: APXvYqw67qH9EJtfoK6NBhcPoKZABNOpobi8xP/81pD0tIt1Ip4UaMQ79X5htfIWNTtQr8u5Ay2A/w== X-Received: by 2002:a17:902:f085:: with SMTP id go5mr78376248plb.53.1558495141624; Tue, 21 May 2019 20:19:01 -0700 (PDT) Received: from 2001-b400-e3a6-9e66-752d-0f2a-4a39-b53d.emome-ip6.hinet.net (2001-b400-e3a6-9e66-752d-0f2a-4a39-b53d.emome-ip6.hinet.net. [2001:b400:e3a6:9e66:752d:f2a:4a39:b53d]) by smtp.gmail.com with ESMTPSA id r64sm44226375pfa.25.2019.05.21.20.18.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 May 2019 20:19:01 -0700 (PDT) From: =?utf-8?B?5pu+5oe35oGp?= Message-Id: <31A706AA-A3D2-46E9-9FB9-586245A6E898@csie.io> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 22 May 2019 11:18:54 +0800 In-Reply-To: <751e597b-bfbe-5e4d-d138-f388ffd3eab7@kth.se> Cc: users@dpdk.org To: Tom Barbette , Adrien Mazarguil , Wenzhuo Lu , Konstantin Ananyev 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> <751e597b-bfbe-5e4d-d138-f388ffd3eab7@kth.se> X-Mailer: Apple Mail (2.3445.104.11) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 all, thanks for previous replying, I tried to find information about flow director in 82599 ixgbevf. In the datasheet = https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/82= 599-10-gbe-controller-datasheet.pdf = ,=20 figure 7-7 shows 82599 NIC supports flow director in virtualization = case. However, I got flow creation failed with =E2=80=9Cfunction not = implemented=E2=80=9D when I tried to create a raw flow rule. Here is the flow I created :=20 struct rte_flow_attr attr; struct rte_flow_item pattern[4];=20 struct rte_flow_action action[4];=20 struct rte_flow *flow =3D NULL;=20 struct rte_flow_action_queue queue =3D { .index =3D rx_q };=20 struct rte_flow_item_eth eth_spec, eth_mask; struct rte_flow_item_ipv4 ip_spec, ip_mask;=20 memset(pattern,0,sizeof(pattern)); memset(action,0,sizeof(action)); memset(&attr,0,sizeof(struct rte_flow_attr)); attr.ingress =3D 1; action[0].type =3D RTE_FLOW_ACTION_TYPE_QUEUE; action[0].conf =3D &queue; action[1].type =3D RTE_FLOW_ACTION_TYPE_END; memset(ð_spec,0,sizeof(struct rte_flow_item_eth)); memset(ð_mask,0,sizeof(struct rte_flow_item_eth)); for(int i=3D0; i Tom Barbette =E6=96=BC 2019=E5=B9=B45=E6=9C=8816=E6=97= =A5 =E4=B8=8B=E5=8D=882:00 =E5=AF=AB=E9=81=93=EF=BC=9A >=20 > Hi, >=20 > 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. >=20 > Eg, for x520, you will have only access to what is called the 2 flex = bytes, see the 82599 datasheet. >=20 > If you grep the code you'll see the constraint are quite huge : >=20 > It will fail if any of these is true : > Mask : > raw_mask->pattern[0] !=3D 0xff || > raw_mask->pattern[1] !=3D 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. >=20 > Value: > raw_spec->relative !=3D 0 || > raw_spec->search !=3D 0 || > raw_spec->reserved !=3D 0 || > raw_spec->offset > IXGBE_MAX_FLX_SOURCE_OFF || > raw_spec->offset % 2 || > raw_spec->limit !=3D 0 || > raw_spec->length !=3D 2 || > /* pattern can't be 0xffff */ > (raw_spec->pattern[0] =3D=3D 0xff && > raw_spec->pattern[1] =3D=3D 0xff)) >=20 > I think XL710 (i40e) will be as restrained. =46rom what I remember the = flex bytes became a flex payload bytes. So you can't even match on the = header. >=20 >=20 > Tom >=20 >=20 > For relevance, other mask stuff : > raw_mask->relative !=3D 0x1 || > raw_mask->search !=3D 0x1 || > raw_mask->reserved !=3D 0x0 || > (uint32_t)raw_mask->offset !=3D 0xffffffff || > raw_mask->limit !=3D 0xffff || > raw_mask->length !=3D 0xffff >=20 >=20 >=20 >=20 > Le 16/05/2019 =C3=A0 07:34, =E6=9B=BE=E6=87=B7=E6=81=A9 a =C3=A9crit : >> 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 =E6=96=BC = 2019=E5=B9=B45=E6=9C=8813=E6=97=A5 =E4=B8=8B=E5=8D=884:49 =E5=AF=AB=E9=81=93= =EF=BC=9A >>>=20 >>> On Sat, May 11, 2019 at 02:20:48AM +0800, Huai-En Tseng wrote: >>>> Thanks for reply, >>>>=20 >>>> Actually I=E2=80=99d like to use rte_flow_item_raw structure with = PPP header, the ICMP format is my little trial. >>>=20 >>> OK, makes sense, there's no pattern item for PPP yet. >>>=20 >>>> I will try X520 next week. >>>>=20 >>>> Another question, is ixgbevf also support RTE_FLOW_ITEM_RAW? >>>=20 >>> The ixgbe driver looks like it does but I'm not sure regarding the = VF >>> variant, Cc'ing maintainers just in case. >>>=20 >>> --=20 >>> Adrien Mazarguil >>> 6WIND >=20