From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 55C1A6A95 for ; Wed, 10 Dec 2014 23:29:33 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 10 Dec 2014 14:27:42 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,554,1413270000"; d="scan'208";a="621846799" Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88]) by orsmga001.jf.intel.com with ESMTP; 10 Dec 2014 14:29:04 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 11 Dec 2014 06:29:04 +0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.182]) by shsmsx102.ccr.corp.intel.com ([169.254.2.216]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 06:29:02 +0800 From: "Zhang, Helin" To: Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH v4] mbuf: fix of enabling all newly added RX error flags Thread-Index: AQHQFFzOtE3RTEW+NEmbeyO057Pa/JyI1wTQ//+Va4CAAPq8YA== Date: Wed, 10 Dec 2014 22:29:02 +0000 Message-ID: References: <1417829617-7185-1-git-send-email-helin.zhang@intel.com> <2233989.0bm00NiAWz@xps13> <17296025.Gs0n2xkUhX@xps13> In-Reply-To: <17296025.Gs0n2xkUhX@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 22:29:34 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Wednesday, December 10, 2014 11:26 PM > To: Zhang, Helin > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v4] mbuf: fix of enabling all newly added = RX > error flags >=20 > 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 'o= l_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 > > > > --- > > > > 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 an= d > mbuf. > > > All > > > > other error flags were added back. > > > > * Assigned error flags with correct and valid values, as their prev= ious > 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. >=20 > 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 think I did understand your point. For those port which does not support = tunneling, if a 'tunneling' packet received, it never knows that's tunneling packet, i= t always treats it as a general IP packet. The "inner" IP is just part of its data. For thi= s case, no outer or inner at all, just an IP header. >=20 > I just suggest to remove the part "(or inner IP)" of the comment. > Do you agree? I got it, actually I wanted to describe it as (or inner IP for tunneling), = as the macro name does not tell it could be inner IP header checksum error for tunneling case= . Regards, Helin >=20 > -- > Thomas