From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 59267A04B3; Mon, 16 Dec 2019 09:47:51 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 32FA91C1A9; Mon, 16 Dec 2019 09:47:51 +0100 (CET) Received: from mail-vs1-f65.google.com (mail-vs1-f65.google.com [209.85.217.65]) by dpdk.org (Postfix) with ESMTP id 975341C191 for ; Mon, 16 Dec 2019 09:47:49 +0100 (CET) Received: by mail-vs1-f65.google.com with SMTP id x18so3635215vsq.4 for ; Mon, 16 Dec 2019 00:47:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ed82cBu7PvO7H3AAKqHksp00Gbc8WGaGbX7lXFVAD2s=; b=ekAcV/Fn6LZ+hXtXtMq+s/HHS/z94uCK4fYhRVA3jAOJG/d6r8LpQbxdSmvoV4Fgpj UqGFj2gaD0l2hxn6sD+/Yt6YQO0BsBq8ND17gPhtfYobJ5dy++0Ng6yLUNNM8Y4+SC33 RKZKhCDfvy1YzYb8Iaor1yW6AJpZIqDC4yYK4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ed82cBu7PvO7H3AAKqHksp00Gbc8WGaGbX7lXFVAD2s=; b=Pk2dszyKiwxeMVkQD97dXoNnD75+s9RP5DNLME/WZkUFEmptBWPtz1gnAWOe02nzAK e1fkgsxWLxL1WmAAkLSUn8RcEhI/48NJwyM+AWzKB0jdmKPNALcVciAURO1oQ9Bb+diI NR4dlrrmMt3pg4DKWeOzcok/UQsOiPwcwAcHIzF86JkwdVqNZe6Sh6n5MvhIlI9UqZkj oQiGgFI0rFjCpEj1YFnIh93ab6Nu0+J+IpXNJFEYnX6zTOrjShiLR3zQLNMnyCdtqMZs 8/n6jvKOv/t4LIWDMyOuhqejjqzZvdA6Hiw6O/Z5YS97203IijXrWBBvxdmOJwD3dk+L iTGw== X-Gm-Message-State: APjAAAXVge9QsYNCmQ9vknHoc1Z7+pbwAojcR4/54s8Lzg1mVVHXV2qN 8epqk54NiZZT8o/x166wx23M7wT98ziFF1E7rzeLMQ== X-Google-Smtp-Source: APXvYqyPjmbvvdBhw1JSsL6BPyL+VBAs+T5cX40b3jpUx+hew39SRWv6M1HHnF97BAs+JHTR3GnewNahtij+icL14RE= X-Received: by 2002:a67:1884:: with SMTP id 126mr19399946vsy.219.1576486068842; Mon, 16 Dec 2019 00:47:48 -0800 (PST) MIME-Version: 1.0 References: <20191216031647.7750-1-somnath.kotur@broadcom.com> <68e1721c-4051-0451-185d-39344a026a38@solarflare.com> In-Reply-To: <68e1721c-4051-0451-185d-39344a026a38@solarflare.com> From: Somnath Kotur Date: Mon, 16 Dec 2019 14:17:37 +0530 Message-ID: To: Andrew Rybchenko Cc: dev , Ferruh Yigit , Olivier Matz Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [RFC PATCH] mbuf: fix to update documentation of PKT_RX_QINQ_STRIPPED 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Mon, Dec 16, 2019 at 12:01 PM Andrew Rybchenko wrote: > > On 12/16/19 6:16 AM, Somnath Kotur wrote: > > Certain hardware may be able to strip and/or save only the outermost > > VLAN instead of both the VLANs in the mbuf in a QinQ scenario. > > To handle such cases, we could re-interpret setting of just PKT_RX_QINQ_STRIPPED > > to indicate that only the outermost VLAN has been stripped by the hardware and > > saved in mbuf->vlan_tci_outer. > > Only When both PKT_RX_QINQ_STRIPPED and PKT_RX_VLAN_STRIPPED are set, the 2 vlans > > have been stripped by the hardware and their tci are saved in mbuf->vlan_tci (inner) > > and mbuf->vlan_tci_outer (outer). > > > > Signed-off-by: Somnath Kotur > > Signed-off-by: JP Lee > > --- > > lib/librte_mbuf/rte_mbuf_core.h | 15 +++++++++++---- > > 1 file changed, 11 insertions(+), 4 deletions(-) > > > > diff --git a/lib/librte_mbuf/rte_mbuf_core.h b/lib/librte_mbuf/rte_mbuf_core.h > > index 9a8557d..db1070b 100644 > > --- a/lib/librte_mbuf/rte_mbuf_core.h > > +++ b/lib/librte_mbuf/rte_mbuf_core.h > > @@ -124,12 +124,19 @@ > > #define PKT_RX_FDIR_FLX (1ULL << 14) > > > > /** > > - * The 2 vlans have been stripped by the hardware and their tci are > > - * saved in mbuf->vlan_tci (inner) and mbuf->vlan_tci_outer (outer). > > + * The outer vlan has been stripped by the hardware and their tci are > > + * saved in mbuf->vlan_tci_outer (outer). > > * This can only happen if vlan stripping is enabled in the RX > > * configuration of the PMD. > > - * When PKT_RX_QINQ_STRIPPED is set, the flags (PKT_RX_VLAN | > > - * PKT_RX_VLAN_STRIPPED | PKT_RX_QINQ) must also be set. > > + * When PKT_RX_QINQ_STRIPPED is set, the flags (PKT_RX_VLAN | PKT_RX_QINQ) > > + * must also be set. > > + * When both PKT_RX_QINQ_STRIPPED and PKT_RX_VLAN_STRIPPED are set, the 2 vlans > > + * have been stripped by the hardware and their tci are saved in > > + * mbuf->vlan_tci (inner) and mbuf->vlan_tci_outer (outer). > > + * This can only happen if vlan stripping is enabled in the RX configuration > > + * of the PMD. > > + * When PKT_RX_QINQ_STRIPPED and PKT_RX_VLAN_STRIPPED are set, > > + * (PKT_RX_VLAN | PKT_RX_QINQ) must also be set. > > */ > > #define PKT_RX_QINQ_STRIPPED (1ULL << 15) > > > > I always thought that PKT_RX_VLAN_STRIPPED means *one* VLAN > stripped regardless if it is outer (if the packet is double > tagged) or inner (if only one VLAN tag was present). > > That's why PKT_RX_QINQ_STRIPPED description says that *two* > VLANs have been stripped. > > What is the problem with such approach? The problem is that RX_VLAN_STRIPPED implies that the stripped VLAN (outer or inner) is saved in mbuf->vlan_tci, correct? There is no way to convey that it is in QinQ mode and yet only outer VLAN has been stripped and saved in mbuf->vlan_tci_outer ?