From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <thomas.monjalon@6wind.com>
Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50])
by dpdk.org (Postfix) with ESMTP id 325E66A8B
for <dev@dpdk.org>; Wed, 10 Dec 2014 16:26:45 +0100 (CET)
Received: by mail-wg0-f50.google.com with SMTP id a1so3927871wgh.37
for <dev@dpdk.org>; Wed, 10 Dec 2014 07:26:45 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:from:to:cc:subject:date:message-id:organization
:user-agent:in-reply-to:references:mime-version
:content-transfer-encoding:content-type;
bh=sm7z2dJFzFfjPyDYAjI73Lla7reL8KRA9Z5tqIRuhIA=;
b=cCpkYtTQnjniQexlOKWt5l2fKBdkJVvujtqXg9/LIPyQIPkeynhz1Cx2OJib6AX7Fz
+apkBVBtmyGrGuoVdmt6cZC54x0hAcIEZemtpOXF+wXT8NlxpZ03NzfOr3vPnPqyyMr8
rWjjSmefZ+3K0cW5n0vWkN/EMCl23qpqr+/q3Yic2Z/q3jmq0IZwUQUqgFXNvZiTguBq
yrlIc1hqrAKptAYWZ0Docq+H9rciMCLZNJWtQTy4lhL6PmdS8O5t5I8pRsunx0lyaygi
BZsnI75J9Z6wSNqVKwStJY4pafzzaNuQIzNRAcko109OnTlk/3DOs6j1TmPgBiXaaAET
qNGA==
X-Gm-Message-State: ALoCoQmJbhckhpq9MSLJyGIkxMGF6fMviBAltc5qNk8NuIDvv+bsCoXXeF2irnxPJnh4nvLL/+B7
X-Received: by 10.180.75.42 with SMTP id z10mr14140002wiv.70.1418225205031;
Wed, 10 Dec 2014 07:26:45 -0800 (PST)
Received: from xps13.localnet ([78.188.139.117])
by mx.google.com with ESMTPSA id ec2sm6726237wib.23.2014.12.10.07.26.41
for <multiple recipients>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Wed, 10 Dec 2014 07:26:44 -0800 (PST)
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: "Zhang, Helin" <helin.zhang@intel.com>
Date: Wed, 10 Dec 2014 16:26:15 +0100
Message-ID: <17296025.Gs0n2xkUhX@xps13>
Organization: 6WIND
User-Agent: KMail/4.14.3 (Linux/3.17.4-1-ARCH; KDE/4.14.3; x86_64; ; )
In-Reply-To: <F35DEAC7BCE34641BA9FAC6BCA4A12E70A7D086F@SHSMSX104.ccr.corp.intel.com>
References: <1417829617-7185-1-git-send-email-helin.zhang@intel.com>
<2233989.0bm00NiAWz@xps13>
<F35DEAC7BCE34641BA9FAC6BCA4A12E70A7D086F@SHSMSX104.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v4] mbuf: fix of enabling all newly added RX
error flags
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Dec 2014 15:26:45 -0000
2014-12-10 13:50, Zhang, Helin:
>
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Sent: Wednesday, December 10, 2014 5:35 PM
> > To: Zhang, Helin
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v4] mbuf: fix of enabling all newly added RX
> > error flags
> >
> > 2014-12-10 16:55, Helin Zhang:
> > > Before redefining mbuf structure, there was lack of free bits in 'ol_flags'
> > > (32 bits in total) for new RX or TX flags. So it tried to reuse
> > > existant bits as most as possible, or even assigning 0 to some of bit
> > > flags. After new mbuf structure defined, there are quite a lot of free
> > > bits. So those newly added bit flags should be assigned with correct
> > > and valid bit values, and getting their names should be enabled as
> > > well. Note that 'RECIP' should be removed, as nowhere uses it.
> > > 'PKT_RX_ERR' is defined to replace all other error bit flags, e.g. MAC error,
> > Oversize error, header buffer overflow error.
> > >
> > > Signed-off-by: Helin Zhang <helin.zhang@intel.com>
> > > ---
> > > lib/librte_mbuf/rte_mbuf.c | 7 ++-----
> > > lib/librte_mbuf/rte_mbuf.h | 9 +++------
> > > lib/librte_pmd_i40e/i40e_rxtx.c | 37
> > > ++++++++++++++++++++-----------------
> > > 3 files changed, 25 insertions(+), 28 deletions(-)
> > >
> > > v2 changes:
> > > * Removed error flag of 'ECIPE' processing only in both i40e PMD and mbuf.
> > All
> > > other error flags were added back.
> > > * Assigned error flags with correct and valid values, as their previous values
> > > were invalid.
> > > * Enabled getting all error flag names.
> > >
> > > v3 changes:
> > > * 'PKT_RX_ERR' is defined to replace error bit flags of MAC error, Oversize
> > > error, header buffer overflow error.
> > > * Removed assigning values to PKT_TX_* bit flags, as it has already been
> > done
> > > in another packet set.
> > >
> > > v4 changes:
> > > * Renamed 'PKT_RX_EIP_CKSUM_BAD' to 'PKT_RX_OUTER_IP_CKSUM_BAD'.
> > > * Fixed the bug of checking error bits of 'Descriptor oversize' and
> > > 'Header buffer oversize'.
> > > * Added debug logs for each RX error.
> > [...]
> > > --- a/lib/librte_mbuf/rte_mbuf.h
> > > +++ b/lib/librte_mbuf/rte_mbuf.h
> > > @@ -83,12 +83,7 @@ extern "C" {
> > > #define PKT_RX_RSS_HASH (1ULL << 1) /**< RX packet with RSS
> > hash result. */
> > > #define PKT_RX_FDIR (1ULL << 2) /**< RX packet with FDIR
> > match indicate. */
> > > #define PKT_RX_L4_CKSUM_BAD (1ULL << 3) /**< L4 cksum of RX pkt.
> > is
> > > not OK. */ -#define PKT_RX_IP_CKSUM_BAD (1ULL << 4) /**< IP cksum of
> > > RX pkt. is not OK. */ -#define PKT_RX_EIP_CKSUM_BAD (0ULL << 0) /**<
> > External IP header checksum error. */
> > > -#define PKT_RX_OVERSIZE (0ULL << 0) /**< Num of desc of an RX
> > pkt oversize. */
> > > -#define PKT_RX_HBUF_OVERFLOW (0ULL << 0) /**< Header buffer
> > overflow. */
> > > -#define PKT_RX_RECIP_ERR (0ULL << 0) /**< Hardware processing
> > error. */
> > > -#define PKT_RX_MAC_ERR (0ULL << 0) /**< MAC error. */
> > > +#define PKT_RX_IP_CKSUM_BAD (1ULL << 4) /**< IP (or inner IP)
> > > +header checksum error. */
> >
> > It can be also an outer IP header in case the device don't support tunneling or is
> > not configured to detect it.
>
> For non-tunneling case, no outer/inner at all, it just has the IP header. The bit flag
> indicates the IP header checksum error.
> For tunneling case, this bit flag indicates the inner IP header checksum error, another
> one for outer IP header checksum error.
> So I don't think this bit can be treated as outer.
I think you didn't understand my comment.
I talk about NICs which don't have tunneling support.
In this case, the outer IP header is seen as a simple IP header.
So, depending on which port is receiving a tunneled packet, this
flag or the dedicated one can be used for outer IP checksum.
I just suggest to remove the part "(or inner IP)" of the comment.
Do you agree?
--
Thomas