From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id 725ED1CB7C for ; Thu, 5 Apr 2018 14:03:12 +0200 (CEST) Received: by mail-wm0-f41.google.com with SMTP id r82so6449352wme.0 for ; Thu, 05 Apr 2018 05:03:12 -0700 (PDT) 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=GLla3viph/k5Cv92vvdyAmvaSbo0CrXaz1kD/7SmKKI=; b=RhuXu589wbgW6Ed/Kf/b1HgZOVgXUx1rhKVi5ME6nRPBFuCyyc4FJKUFDxRKweF0hs AZKjN2jVQNFpeaKfCh8gqgLV56pa1N19KXvBxp0pVIaeyDWyTzhuDKlirKbgcrO2Hv/o M2QPQU9UoFj+2WKJGyhgefu9h+P1tiWpqWJxuISCh7XHMJcK67LAUOm1rpHKn4fagOwf VvVRKd0XOsAX7u6Q0Ym+Wqzo3yi932CjP99z7ZN0nReBMMDupRq+hDy3t4fSI1NJdjrs 2IjQPM1HBZ5ZlgIbcX8hygCakNm2AcU2REUxVEumR+zli+OryDlzapOUsCUpZrAHJMfQ 03+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=GLla3viph/k5Cv92vvdyAmvaSbo0CrXaz1kD/7SmKKI=; b=J9qJkiTzrLs9amDXth0UKzogjzHysy5IiGimEvlL3R3kiaVQ4Jyp/ZDbbn5p2dBhwi +A0whPgBMgHckipsGLKbJzVyuhNesL7AqpxTm0VS3M94i/raRUUn/VHKUmOamKlsvyNJ tvB0vtAzsgKOyyoIO2CrBMc0FusPUmDo7HVdVOHvUVFE5w8zDiI120BS5apN0NIVr+tA IHOIkGgWAuK+Cjtuk07Pf2Elrht/JV9+TsdLmJ1lC8rO2KFtCBHKh9zF2jjLQscZG6Ti DAJZbCiL4vYAfPcaU5UKmVs8nFSl3Ecq1kaCviwCRWFSPDuqYdYAqyMFdXty9NBKEhx1 2mmw== X-Gm-Message-State: ALQs6tDjVaoAaGpccLJiSKNWuz0p0lgHACgU+bbQSAJVyI4xaGn6AdFI mVOhKciEe2m7pH7cyDgCNUhHmA== X-Google-Smtp-Source: AIpwx49cezI6P0p0xATNk0geeSXrq3MlMu8j+agn3Xu2VAgsSkCI/mwj2ZpFop6o61tNT3X0roQZRw== X-Received: by 10.28.54.88 with SMTP id d85mr11357551wma.2.1522929792182; Thu, 05 Apr 2018 05:03:12 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id b5sm1383028wrf.40.2018.04.05.05.03.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Apr 2018 05:03:11 -0700 (PDT) Date: Thu, 5 Apr 2018 14:02:58 +0200 From: Adrien Mazarguil To: =?utf-8?B?TsOpbGlv?= Laranjeiro Cc: Thomas Monjalon , Ferruh Yigit , dev@dpdk.org, Wenzhuo Lu , Jingjing Wu , Ajit Khaparde , Somnath Kotur , John Daley , Hyong Youb Kim , Beilei Xing , Qi Zhang , Konstantin Ananyev , Yongseok Koh , Jacek Siuda , Tomasz Duszynski , Dmitri Epshtein , Natalie Samsonov , Jianbo Liu , Andrew Rybchenko , Pascal Mazon Message-ID: <20180405120258.GJ4957@6wind.com> References: <20180404150312.12304-1-adrien.mazarguil@6wind.com> <20180404150312.12304-12-adrien.mazarguil@6wind.com> <20180405095510.rufofyaek6aqqenw@laranjeiro-vm.dev.6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180405095510.rufofyaek6aqqenw@laranjeiro-vm.dev.6wind.com> Subject: Re: [dpdk-dev] [PATCH v1 11/16] ethdev: refine TPID handling in flow API 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: Thu, 05 Apr 2018 12:03:12 -0000 On Thu, Apr 05, 2018 at 11:55:10AM +0200, Nélio Laranjeiro wrote: > On Wed, Apr 04, 2018 at 05:56:49PM +0200, Adrien Mazarguil wrote: > > TPID handling in rte_flow VLAN and E_TAG pattern item definitions is not > > consistent with the normal stacking order of pattern items, which is > > confusing to applications. > > > > Problem is that when followed by one of these layers, the EtherType field > > of the preceding layer keeps its "inner" definition, and the "outer" TPID > > is provided by the subsequent layer, the reverse of how a packet looks like > > on the wire: > > > > Wire: [ ETH TPID = A | VLAN EtherType = B | B DATA ] > > rte_flow: [ ETH EtherType = B | VLAN TPID = A | B DATA ] > > > > Worse, when QinQ is involved, the stacking order of VLAN layers is > > unspecified. It is unclear whether it should be reversed (innermost to > > outermost) as well given TPID applies to the previous layer: > > > > Wire: [ ETH TPID = A | VLAN TPID = B | VLAN EtherType = C | C DATA ] > > rte_flow 1: [ ETH EtherType = C | VLAN TPID = B | VLAN TPID = A | C DATA ] > > rte_flow 2: [ ETH EtherType = C | VLAN TPID = A | VLAN TPID = B | C DATA ] > > > > While specifying EtherType/TPID is hopefully rarely necessary, the stacking > > order in case of QinQ and the lack of documentation remain an issue. > > > > This patch replaces TPID in the VLAN pattern item with an inner > > EtherType/TPID as is usually done everywhere else (e.g. struct vlan_hdr), > > clarifies documentation and updates all relevant code. > > > > Summary of changes for PMDs that implement ETH, VLAN or E_TAG pattern > > items: > > > > - bnxt: EtherType matching is supported, and vlan->inner_type overrides > > eth->type if the latter has standard TPID value 0x8100, otherwise an > > error is triggered. > > > > - e1000: EtherType matching is only supported with the ETHERTYPE filter, > > which does not support VLAN matching, therefore no impact. > > > > - enic: same as bnxt. > > > > - i40e: same as bnxt with a configurable TPID value for the FDIR filter, > > with existing limitations on allowed EtherType values. The remaining > > filter types (VXLAN, NVGRE, QINQ) do not support EtherType matching. > > > > - ixgbe: same as e1000. > > > > - mlx4: EtherType/TPID matching is not supported, no impact. > > > > - mlx5: same as bnxt. > > > > - mrvl: EtherType matching is supported but eth->type cannot be specified > > when a VLAN item is present. However vlan->inner_type is used if > > specified. > > > > - sfc: same as bnxt with QinQ TPID value 0x88a8 additionally supported. > > > > - tap: same as bnxt. > > > > Signed-off-by: Adrien Mazarguil > > @@ -1306,12 +1309,21 @@ mlx5_flow_create_vlan(const struct rte_flow_item *item, > > */ > > if (!eth->mask.vlan_tag) > > goto error; > > + /* Exactly one TPID value is allowed if specified. */ > > + if ((eth->val.ether_type & eth->mask.ether_type) != > > + (RTE_BE16(0x8100) & eth->mask.ether_type)) { > > You can use ETHER_TYPE_VLAN present in rte_ether.h instead of hard coded > values. Good catch, I forgot about those macros. I'll make the change in all impacted code in the next revision. -- Adrien Mazarguil 6WIND