From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0112.outbound.protection.outlook.com [104.47.32.112]) by dpdk.org (Postfix) with ESMTP id 8371D914 for ; Wed, 8 Mar 2017 17:17:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=technicolor.onmicrosoft.com; s=selector1-technicolor-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=D9GktF/nJGANo9fJ71SRWKpguu9G9H+EeU7jYfpUMf0=; b=RfbIz0jQKV/eMXLv9UqyyIbuvNMX6EDjnKLtT3hD1ZT9R1emU3kOIRoMH5dLXYkD6w3xdBWZGuyabEu7mCrpK9PvsszjQ4Z8CL6hr6SL2QmM19EEgHYjncUnnWH97O1BVN1HM20ZNK8ekl7Vdqs64y7q7ou7PFmHmGNsUCSlsP4= Received: from CY4PR02MB2552.namprd02.prod.outlook.com (10.173.41.11) by CY4PR02MB2552.namprd02.prod.outlook.com (10.173.41.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Wed, 8 Mar 2017 16:17:33 +0000 Received: from CY4PR02MB2552.namprd02.prod.outlook.com ([10.173.41.11]) by CY4PR02MB2552.namprd02.prod.outlook.com ([10.173.41.11]) with mapi id 15.01.0947.020; Wed, 8 Mar 2017 16:17:33 +0000 From: Le Scouarnec Nicolas To: Adrien Mazarguil CC: "Lu, Wenzhuo" , users , Jan Medala , Evgeny Schemeilin , Stephen Hurd , Jerin Jacob , Rahul Lakkireddy , John Daley , Matej Vido , Helin Zhang , Konstantin Ananyev , Jingjing Wu , Jing Chen , Alejandro Lucero , Harish Patil , Rasesh Mody , "Andrew Rybchenko" , Nelio Laranjeiro , Vasily Philipov , "Pascal Mazon" , Thomas Monjalon Thread-Topic: Issues with ixgbe and rte_flow Thread-Index: AQHSly9VSVacWJmR5EC8Uqr0D2ovhaGKMkmAgAB1ebWAAG7JgIAAB/ek Date: Wed, 8 Mar 2017 16:17:33 +0000 Message-ID: References: <6A0DE07E22DDAD4C9103DF62FEBC09093B56D514@shsmsx102.ccr.corp.intel.com> , <20170308154131.GQ3790@6wind.com> In-Reply-To: <20170308154131.GQ3790@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Nicolas.LeScouarnec@technicolor.com; x-originating-ip: [165.225.76.54] x-ms-office365-filtering-correlation-id: 6c8e31e2-d6e8-4302-af17-08d4663ea0de x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR02MB2552; x-microsoft-exchange-diagnostics: 1; CY4PR02MB2552; 7:yR1EmKVRotrJBTg+feBaLRpHiFVRDvV/ox5KDzsOyf3nCN4j0OZ8S7lImj+3Ozhs3OAwW/aedY1UDLvcfy+IA1mpFqq7kgf9WlA6J0yXiHduyXibpNZ8AahVEAusGM/Bt3UYO6FwKgen1zZTQ0mkoyq9CTNXGAow2OXIKYUhUj1FWengcMZxuUYx5kWwk0B8iNaE9KxSbAsXOp8qZ/ZsixqXemnmUnO0HKXed5CVGTvSnbhVnk3PGAkVaUl3DmFqYTPkJAYxeYJQSEnFe+4FpRd1KZCpunnt7t8HBWRgKSUXavLYxbhb6BGMtIMtYJf07Ro8WYainQVsfxgElY/1kw==; 20:yNWJGtLi0nF1B5QBYpIL3thTt0CFtmW+rq696bx+SN0aNs0OQX5rPxrJchhIDHAKAmZAmE1yISOlTNxvPaRGe7YhkidgFJDUogTksvcIK6COKIIT8pE4lLmnP8ax7plGj2NO7kO3S4eVxfeDzJbzGqAycK9+emjGg63CFry4vIc= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:CY4PR02MB2552; BCL:0; PCL:0; RULEID:; SRVR:CY4PR02MB2552; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39850400002)(39860400002)(39840400002)(39450400003)(24454002)(377454003)(66066001)(53546006)(122556002)(39060400002)(102836003)(189998001)(5660300001)(2900100001)(33656002)(3846002)(8936002)(2906002)(93886004)(7416002)(54356999)(50986999)(6116002)(76176999)(4326008)(305945005)(7736002)(74316002)(86362001)(54906002)(3660700001)(9686003)(3280700002)(8676002)(99286003)(229853002)(106116001)(77096006)(38730400002)(25786008)(110136004)(7696004)(53936002)(2950100002)(6916009)(55016002)(6506006)(575784001)(81166006)(6246003)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR02MB2552; H:CY4PR02MB2552.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; received-spf: None (protection.outlook.com: technicolor.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: technicolor.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2017 16:17:33.6536 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 036da35c-ba43-4e4a-9bff-72ec0f508621 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR02MB2552 X-Mailman-Approved-At: Wed, 08 Mar 2017 21:46:54 +0100 Subject: Re: [dpdk-users] Issues with ixgbe and rte_flow 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: , X-List-Received-Date: Wed, 08 Mar 2017 16:17:36 -0000 Removing dev to avoid flooding too much people.=A0 Talking about API/ABI breakage,=A0PMD maintainers / users might be interest= ed by this comment that got stripped from the initial message: I also have = a side comment which might be more related to the general rte_flow API than= to the specific implementation in ixgbe. I don't know if it is specific to= ixgbe's implementation but, as a user, the rte_flow_error returned was not= very useful for it does return the error of the last tried filter-type (L2= tunnel in ixgbe), and not the error of the filter-type that my setup shoul= d use (flow director). I had to change the order in which filters are tried= in ixgbe code to get a more useful error message. As NICs can have several= filter-types, It would be be useful to the user if rte_flow_validate/creat= e could return the errors for all filter types tried although that would re= quire to change the rte_flow API and returning an array of rte_flow_error a= nd not a single struct. Best regards, Nicolas Le Scouarnec From: Adrien Mazarguil Sent: Wednesday, March 8, 2017 4:41 PM To: Le Scouarnec Nicolas Cc: Lu, Wenzhuo; dev; users; Jan Medala; Evgeny Schemeilin; Stephen Hurd; J= erin Jacob; Rahul Lakkireddy; John Daley; Matej Vido; Helin Zhang; Konstant= in Ananyev; Jingjing Wu; Jing Chen; Alejandro Lucero; Harish Patil; Rasesh = Mody; Andrew Rybchenko; Nelio Laranjeiro; Vasily Philipov; Pascal Mazon; T= homas Monjalon Subject: Re: Issues with ixgbe and rte_flow =A0 =20 ** WARNING: This mail is from an external source ** CC'ing users@dpdk.org since this issue primarily affects rte_flow users, an= d several PMD maintainers to get their opinion on the matter, see below. On Wed, Mar 08, 2017 at 09:24:26AM +0000, Le Scouarnec Nicolas wrote: > My response is inline bellow, and further comment on the code excerpt als= o > > > From: Lu, Wenzhuo > Sent: Wednesday, March 8, 2017 4:16 AM > To: Le Scouarnec Nicolas; dev@dpdk.org; Adrien Mazarguil (adrien.mazargui= l@6wind.com) > Cc: Yigit, Ferruh > Subject: RE: Issues with ixgbe and rte_flow > > >> I have been using the new API rte_flow to program filtering on an X540= (ixgbe) > >> NIC. My goal is to send packets from different VLANs to different queu= es > >> (filtering which should be supported by flow director as far as I unde= rstand). I > >> enclosed the setup code at the bottom of this email. > >> For reference, here is the setup code I use > >> > >>=A0=A0=A0=A0=A0=A0 vlan_spec.tci =3D vlan_be; > >>=A0=A0=A0=A0=A0=A0 vlan_spec.tpid =3D 0; > >> > >>=A0=A0=A0=A0=A0=A0 vlan_mask.tci =3D rte_cpu_to_be_16(0x0fff); > >>=A0=A0=A0=A0=A0=A0 vlan_mask.tpid =3D=A0 0; > > >To my opinion, this setting is not right. As we know, vlan tag is insert= ed between MAC source address and Ether type. > >So if we have a MAC+VLAN+IPv4 packet, the vlan_spec.tpid should be 0x810= 0, the eth_spec.type should be 0x0800. > >+ Adrien, the author. He can correct me if I'm wrong. That's right, however the confusion is understandable, perhaps the documentation should be clearer. It currently states what follows without describing the reason: =A0/** =A0 * RTE_FLOW_ITEM_TYPE_VLAN =A0 * =A0 * Matches an 802.1Q/ad VLAN tag. =A0 * =A0 * This type normally follows either RTE_FLOW_ITEM_TYPE_ETH or =A0 * RTE_FLOW_ITEM_TYPE_VLAN. =A0 */ > Ok, I apologize, you're right. Being more used to the software-side than = to the hardware-side, I misunderstood struct rte_flow_item_vlan and though = it was the "equivalent" of struct vlan_hdr, in which case the vlan_hdr cont= ains the type of the encapsulated frame. > > (=A0 /** >=A0 * Ethernet VLAN Header. >=A0 * Contains the 16-bit VLAN Tag Control Identifier and the Ethernet typ= e >=A0 * of the encapsulated frame. >=A0 */ > struct vlan_hdr { >=A0=A0=A0=A0=A0=A0 uint16_t vlan_tci; /**< Priority (3) + CFI (1) + Identi= fier Code (12) */ >=A0=A0=A0=A0=A0=A0 uint16_t eth_proto;/**< Ethernet type of encapsulated f= rame. */ > } __attribute__((__packed__));=A0=A0=A0=A0=A0=A0=A0 ) Indeed, struct vlan_hdr and struct rte_flow_item_vlan are not mapped at the same offset; the former includes EtherType of the inner packet (eth_proto), while the latter describes the inserted VLAN header itself starting with TPID. This approach was chosen for rte_flow for consistency with the fact each pattern item describes exactly one protocol header, even though in the case of VLAN and other layer 2.5 protocols, some happen to be embedded. IPv4/IPv6 options will be provided as separate items in a similar fashion. It also allows adding/removing VLAN tags to an existing rule without modifying the EtherType of the inner frame. Now assuming you're not the only one facing that issue, if the current definition does not make sense, perhaps we can update the API before it's too late. I'll attempt to summarize it with an example below. In any case, matching nonspecific VLAN-tagged and QinQ UDPv4 packets in testpmd is written as: =A0flow create 0 pattern eth / vlan / ipv4 / udp / end actions queue 1 / en= d =A0flow create 0 pattern eth / vlan / vlan / ipv4 / udp / end actions queue= 1 / end However, with the current API described above, specifying inner/outer EtherTypes for the above packets yields (as a reminder, 0x8100 stands for VLAN, 0x8000 for IPv4 and 0x88A8 for QinQ): #1 =A0flow create 0 pattern eth type is 0x8000 / vlan tpid is 0x8100 / ipv4 / = udp / actions queue 1 / end =A0flow create 0 pattern eth type is 0x8000 / vlan tpid is 0x88A8 / vlan tp= id is 0x8100 / ipv4 / udp / actions queue 1 / end Instead of the arguably more accurate (renaming "tpid" to "inner_type" for clarity): #2 =A0flow create 0 pattern eth type is 0x8100 / vlan type is 0x8000 / ipv4 / = udp / actions queue 1 / end =A0flow create 0 pattern eth type is 0x88A8 / vlan inner_type is 0x8100 / v= lan inner_type is 0x8000 / ipv4 / udp / actions queue 1 / end So, should the VLAN item be updated to behave as described in #2? Note: doing so will cause a serious API/ABI breakage, I know it was not supposed to happen according to the rte_flow sales pitch, but hey. -- Adrien Mazarguil 6WIND =