From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by dpdk.org (Postfix) with ESMTP id E22042716 for ; Tue, 26 Apr 2016 02:16:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4447; q=dns/txt; s=iport; t=1461629779; x=1462839379; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=I6+sTKB43eZejuWkHym/ptJuMGphvn51c+UYzMCUz/k=; b=iRM+/xagR18oZFc9hjzaVix1W8gUACNpgnPa8U1cF/3rm1G4Oh1COxuq 5oz+HkrIPiY4i2PRL9J3O+QW/T4G82dQ5UjjVGLfiPb4jX4EpZ1yQocTB w94iSCOGx0iN27NG/u5VTD29ry6prOmtMGVRfHBYb7kuLxEo2fszKsNpL A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D6AQAgsh5X/4gNJK1egziBUAa3ZoIPA?= =?us-ascii?q?Q2BdIYOAoE9OBQBAQEBAQEBZSeEQQEBAQQnE0sEAgEIEQQBAQEeCQcyFAkIAQE?= =?us-ascii?q?EARIIE4gPwykBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiGES4oVBZgPAY4OjxdFj?= =?us-ascii?q?mkBHgEBQoNrbIgBfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,534,1454976000"; d="scan'208";a="101242689" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Apr 2016 00:16:17 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3Q0GH3n025002 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Apr 2016 00:16:17 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 25 Apr 2016 19:16:17 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1104.009; Mon, 25 Apr 2016 19:16:17 -0500 From: "John Daley (johndale)" To: Olivier Matz , "Ananyev, Konstantin" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] PKT_RX_VLAN_PKT when VLAN stripping is disabled Thread-Index: AdGcJLb1bs00/Tr/R5uEj1zfkCb1SAAbv2nQAKPsbwAACfFCYA== Date: Tue, 26 Apr 2016 00:16:16 +0000 Message-ID: References: <55ece514189d46d59cca2217214d89be@XCH-RCD-007.cisco.com> <2601191342CEEE43887BDE71AB97725836B415A3@irsmsx105.ger.corp.intel.com> <571E20C0.2080509@6wind.com> In-Reply-To: <571E20C0.2080509@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.145.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] PKT_RX_VLAN_PKT when VLAN stripping is disabled X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 00:16:19 -0000 Hi Olivier and Ananyev, I like the new packet types and how they work the same for VLAN and QINQ. J= ust so I understand your suggestion, X710 (as it seems to work today) would= not set RTE_PTYPE_L2_ETHER_VLAN in dev_supported_ptypes_get() because it = does not know how to determine that packet type in the receive path if stri= pping is disabled? But if stripping was enabled, the application could stil= l trust m->vlan_tci if the flag was set? Re changing the meaning of the PKT_RX_VLAN_PKT flag- I think it could cause= hard to find errors and confusion. I would rather see the flag deprecated = and a new one defined. Perhaps the flag could be called PKT_RX_VLAN_STRIPPE= D*. Maybe another less elegant but more compatible solution would be just keep = the Niantic behavior and fix other pmd's to match its behavior. For X710, w= ith vlan stripping disabled this might mean looking at each packet's Ethern= et type and set the flag accordingly. It might not be too expensive since = Ethernet type is in the 1st cacheline and hopefully prefetched. Thoughts? *In the future perhaps another flag could be added called PKT_RX_VLAN_TCI_V= ALID. This may not be the same as PKT_RX_VLAN_STRIPPED- enic and maybe some= other nics are able to set vlan_tci even when not stripping vlan tags and = this feature could be exposed with this separate flag. -john > -----Original Message----- > From: Olivier Matz [mailto:olivier.matz@6wind.com] > Sent: Monday, April 25, 2016 6:51 AM > To: Ananyev, Konstantin ; John Daley > (johndale) ; dev@dpdk.org > Subject: Re: [dpdk-dev] PKT_RX_VLAN_PKT when VLAN stripping is disabled >=20 > Hi, >=20 > On 04/25/2016 02:02 PM, Ananyev, Konstantin wrote: > > Hi John, > > From rte_mbuf.h: > > #define PKT_RX_VLAN_PKT (1ULL << 0) /**< RX packet is a 802.1q VL= AN > packet. */ > > So yes, in theory it should be set up for vlan packet with both strippi= ng > on/off. > > The problem is that (as far as I know) when VLAN stripping is disabled > > FVL RXD doesn't contain information does that packet contain a VLAN or > not. > > Don't really know what is the best option in that case: keep things as > > it is or change the meaning of the VLAN_PKT flag to indicate is > mbuf.vlan_tci field is valid or not. > > Konstantin >=20 > It seems the meaning of the PKT_RX_VLAN_PKT bit depends on the port > configuration: > - if vlan stripping is configured, it means VLAN is present in vlan_tci > mbuf field > - if not configured, it means a VLAN is present in the packet >=20 > I don't think this is a good behavior since the application has to know t= he port > configuration to properly interpret the meaning of the flag. >=20 > I suggest to change the meaning of this flag to: "vlan was stripped by > hardware, and vlan tag is now located in m->vlan_tci". >=20 > The same could apply to PKT_RX_QINQ_PKT and m->outer_vlan_tci. >=20 > We could add a new packet_type to tell if the mbuf is a VLAN/QinQ is > detected in the packet but not stripped. >=20 > Example: >=20 > - vlan stripping is disabled >=20 > - vlan packet recvd: flags=3D0, ptype=3DRTE_PTYPE_L2_ETHER_VLAN > - qinq packet recvd: flags=3D0, ptype=3DRTE_PTYPE_L2_ETHER_QINQ >=20 > - vlan stripping is enabled >=20 > - vlan packet recvd: flags=3DPKT_RX_VLAN_PKT, > ptype=3DRTE_PTYPE_L2_ETHER, > m->vlan_tci=3Did > - qinq packet recvd: flags=3DPKT_RX_VLAN_PKT|PKT_RX_QINQ_PKT, > ptype=3DRTE_PTYPE_L2_ETHER, m->vlan_tci=3Did, m->vlan_tci_outer= =3Did >=20 >=20 > Thoughts? >=20 >=20 >=20 > > > >> -----Original Message----- > >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of John Daley > >> (johndale) > >> Sent: Friday, April 22, 2016 12:37 AM > >> To: dev@dpdk.org > >> Subject: [dpdk-dev] PKT_RX_VLAN_PKT when VLAN stripping is disabled > >> > >> Hi, > >> > >> When VLAN stripping is disabled, X710 and 82599ES act differently for > >> me in this case when receiving VLAN tagged packets. On 82599ES the fla= g > is set but on X710 the flag not set. > >> > >> Do I maybe have old X710 firmware? Or is it not set for X710 on > >> purpose in this case and instead the flag is used to indicate if vlan_= tci is > valid? Right now the enic pmd does what my X710 does, which I think is > incorrect and I want to fix it. > >> > >> Thanks, > >> John > >