From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id 96E77379B for ; Wed, 8 Mar 2017 16:41:40 +0100 (CET) Received: by mail-wm0-f52.google.com with SMTP id n11so34116558wma.0 for ; Wed, 08 Mar 2017 07:41:40 -0800 (PST) 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:content-transfer-encoding:in-reply-to; bh=4po3WgtHId8huqWOMLjjAMuNoCsmTLy00aX288NR1Sc=; b=gQ37fs7gWX+HLp/a6O+BbMrmaHjZri2wmolhlfgmjM0YacSA+GQ7S4A5OJdt49RTgz h74TLcgJs73A2TSgq4eWZIo968TyRHrVMMmmgaf4KzJ8k6JdX0jV6uPAAKtBElTFVNni PuVb0C7ArJnuANm09LHeUU2aVzkOxR4CsQqDsvs7a7zXdajAkMceDkBCMAtvQXJvnGQw 0wy2AuWazO0BeypTh9u3jnECJgx9n1HxuDLxV3zcJg1EInkvW3gv55zya6A9nL3vZzYy kTSiDhrNw77uLkFlZtZc9kfLv4J+m3bv91RrsFPCAMLjSuwsFVGYTC8ofc5fYViNWH/M G6/w== 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:content-transfer-encoding :in-reply-to; bh=4po3WgtHId8huqWOMLjjAMuNoCsmTLy00aX288NR1Sc=; b=JWkUlncOmh3yeCHx65/Rqu1hqf8JddR8C3/ojN1F1zdesfrcMb42HsVKYUzyX4aVd9 /ysFdEKOrMLp1f6/+pOUSkVAtCKgcfkmT9pzETGeTejVCEnS5Xx2H+DKxpMNGXufidNb Trj4iJFlG30I/Dq/J7nDfEdEK8LNgPrvwd+69wdp4oHgniZQT3SCguity48+Un4XZgrv PE1lIgw5ToYxfbk8OY6eREdpE8OwOxPdWPCSXms6GUSSa3fgzDhyOqVae5e3vRxSwFVa /3HQQd/O6YO8jmxHSqgG1LLAst97vYUkq89fQLNWE+9ZOBThhCOMZJcP9yjQG7vABCap SvDQ== X-Gm-Message-State: AMke39kl+hn+gbZ++SPAfZPPaVNDelEXfkEVtzqZsh4nOpD8hYjHqpZd1cSVxraVWOU58cmk X-Received: by 10.28.133.203 with SMTP id h194mr6219559wmd.122.1488987700170; Wed, 08 Mar 2017 07:41:40 -0800 (PST) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id n59sm4629334wrb.54.2017.03.08.07.41.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Mar 2017 07:41:39 -0800 (PST) Date: Wed, 8 Mar 2017 16:41:31 +0100 From: Adrien Mazarguil To: Le Scouarnec Nicolas Cc: "Lu, Wenzhuo" , dev , 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 Message-ID: <20170308154131.GQ3790@6wind.com> References: <6A0DE07E22DDAD4C9103DF62FEBC09093B56D514@shsmsx102.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 15:41:40 -0000 CC'ing users@dpdk.org since this issue primarily affects rte_flow users, and 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 also > > > From: Lu, Wenzhuo > Sent: Wednesday, March 8, 2017 4:16 AM > To: Le Scouarnec Nicolas; dev@dpdk.org; Adrien Mazarguil (adrien.mazarguil@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 queues > >> (filtering which should be supported by flow director as far as I understand). I > >> enclosed the setup code at the bottom of this email. > >> For reference, here is the setup code I use > >> > >>       vlan_spec.tci = vlan_be; > >>       vlan_spec.tpid = 0; > >> > >>       vlan_mask.tci = rte_cpu_to_be_16(0x0fff); > >>       vlan_mask.tpid =  0; > > >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. That's right, however the confusion is understandable, perhaps the documentation should be clearer. It currently states what follows without describing the reason: /** * RTE_FLOW_ITEM_TYPE_VLAN * * Matches an 802.1Q/ad VLAN tag. * * This type normally follows either RTE_FLOW_ITEM_TYPE_ETH or * RTE_FLOW_ITEM_TYPE_VLAN. */ > 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 contains the type of the encapsulated frame. > > ( /** > * Ethernet VLAN Header. > * Contains the 16-bit VLAN Tag Control Identifier and the Ethernet type > * of the encapsulated frame. > */ > struct vlan_hdr { > uint16_t vlan_tci; /**< Priority (3) + CFI (1) + Identifier Code (12) */ > uint16_t eth_proto;/**< Ethernet type of encapsulated frame. */ > } __attribute__((__packed__)); ) 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: flow create 0 pattern eth / vlan / ipv4 / udp / end actions queue 1 / end flow 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 flow create 0 pattern eth type is 0x8000 / vlan tpid is 0x8100 / ipv4 / udp / actions queue 1 / end flow create 0 pattern eth type is 0x8000 / vlan tpid is 0x88A8 / vlan tpid is 0x8100 / ipv4 / udp / actions queue 1 / end Instead of the arguably more accurate (renaming "tpid" to "inner_type" for clarity): #2 flow create 0 pattern eth type is 0x8100 / vlan type is 0x8000 / ipv4 / udp / actions queue 1 / end flow create 0 pattern eth type is 0x88A8 / vlan inner_type is 0x8100 / vlan 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