From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 4A83F1BBE for ; Wed, 8 Mar 2017 04:16:39 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2017 19:16:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,261,1486454400"; d="scan'208";a="1119794137" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga001.fm.intel.com with ESMTP; 07 Mar 2017 19:16:35 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 7 Mar 2017 19:16:34 -0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.88]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.204]) with mapi id 14.03.0248.002; Wed, 8 Mar 2017 11:16:32 +0800 From: "Lu, Wenzhuo" To: Le Scouarnec Nicolas , "dev@dpdk.org" , "Adrien Mazarguil (adrien.mazarguil@6wind.com)" CC: "Yigit, Ferruh" Thread-Topic: Issues with ixgbe and rte_flow Thread-Index: AQHSly9VSVacWJmR5EC8Uqr0D2ovhaGKMkmA Date: Wed, 8 Mar 2017 03:16:31 +0000 Message-ID: <6A0DE07E22DDAD4C9103DF62FEBC09093B56D514@shsmsx102.ccr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] Issues with ixgbe and rte_flow 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, 08 Mar 2017 03:16:40 -0000 Hi Le Scouarnec, > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Le Scouarnec Nicolas > Sent: Tuesday, March 7, 2017 7:12 PM > To: dev@dpdk.org > Cc: Yigit, Ferruh > Subject: [dpdk-dev] Issues with ixgbe and rte_flow >=20 > Dear all, >=20 > I have been using the new API rte_flow to program filtering on an X540 (i= xgbe) > NIC. My goal is to send packets from different VLANs=A0to different queue= s > (filtering which should be supported by flow director as far as I underst= and). I > enclosed the setup code at the bottom of this email. However, the code in= ixgbe > rejects the request I formulated. I looked at the rte_flow related code i= n ixgbe > and I found some weird checkings in function ixgbe_parse_fdir_filter_norm= al. > The code verifies that vlan_spec->tpid =3D=3D ETHER_TYPE_VLAN, which shou= ld > never happen on real packets, as it is eth_spec->type which has this valu= e in > typical setups. The same comment applies to the mask, only eth_mask->tpid > should be required to be 0xffff. Overall, unless I misunderstood the rte_= flow API, > the checks should be done on eth_spec/eth_mask rather than > vlan_spec/vlan_mask. >=20 > I also have a side comment which might be more related to the general rte= _flow > API than to the specific implementation in ixgbe. The rte_flow_error retu= rned is > not very useful for it does return the error of the last tried filter-typ= e (L2 tunnel > in ixgbe), and not the error of the filter-type that my setup should use = (flow > director). As NICs can have several filter-types, It would be be useful t= o the user > if rte_flow_validate/create could return the errors for all filter types = tried > although that would require to change the rte_flow API and returning an a= rray > of rte_flow_error and not a single struct. >=20 > Excerpt of the code that reject my filtering rule: >=20 > if (vlan_spec->tpid !=3D rte_cpu_to_be_16(ETHER_TYPE_VLAN))= { > memset(rule, 0, sizeof(struct ixgbe_fdir_rule)); > rte_flow_error_set(error, EINVAL, > RTE_FLOW_ERROR_TYPE_ITEM, > item, "Not supported by fdir filter"); > return -rte_errno; > } >=20 >=20 > rule->ixgbe_fdir.formatted.vlan_id =3D vlan_spec->tci; >=20 >=20 > if (vlan_mask->tpid !=3D (uint16_t)~0U) { > memset(rule, 0, sizeof(struct ixgbe_fdir_rule)); > rte_flow_error_set(error, EINVAL, > RTE_FLOW_ERROR_TYPE_ITEM, > item, "Not supported by fdir filter"); > return -rte_errno; > } >=20 > For reference, here is the setup code I use >=20 > struct rte_flow_attr attr; > attr.group =3D 0; > attr.priority =3D 0; > attr.egress =3D 0; > attr.ingress =3D 1; >=20 >=20 > struct rte_flow_item_eth eth_mask; > struct rte_flow_item_eth eth_spec; > struct rte_flow_item_vlan vlan_mask; > struct rte_flow_item_vlan vlan_spec; > struct rte_flow_action_queue queue; >=20 >=20 > struct rte_flow_item items[3]; > items[0].type =3D RTE_FLOW_ITEM_TYPE_ETH; > items[1].type =3D RTE_FLOW_ITEM_TYPE_VLAN; > items[0].last =3D NULL; > items[0].spec =3D ð_spec; > items[0].mask =3D ð_mask; > items[1].last =3D NULL; > items[1].spec =3D &vlan_spec; > items[1].mask =3D &vlan_mask; > items[2].type =3D RTE_FLOW_ITEM_TYPE_END; >=20 >=20 > eth_mask.src =3D ETH(00,00,00,00,00,00); > eth_mask.dst =3D ETH(ff,ff,ff,ff,ff,ff); > eth_mask.type =3D 0xffff; >=20 >=20 > eth_spec.src =3D ETH(00,00,00,00,00,00); > eth_spec.dst =3D *dst; > eth_spec.type =3D rte_cpu_to_be_16(ETHER_TYPE_VLAN); >=20 >=20 > vlan_spec.tci =3D vlan_be; > vlan_spec.tpid =3D 0; >=20 >=20 > vlan_mask.tci =3D rte_cpu_to_be_16(0x0fff); > vlan_mask.tpid =3D =A00; To my opinion, this setting is not right. As we know, vlan tag is inserted = between MAC source address and Ether type. So if we have a MAC+VLAN+IPv4 packet, the vlan_spec.tpid should be 0x8100, = the eth_spec.type should be 0x0800. + Adrien, the author. He can correct me if I'm wrong.