From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by dpdk.org (Postfix) with ESMTP id 604E12E8A for ; Thu, 11 Dec 2014 12:16:08 +0100 (CET) Received: by mail-wi0-f169.google.com with SMTP id r20so1092880wiv.4 for ; Thu, 11 Dec 2014 03:16:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PBoWq2GruR3gM7V2NRqpVytbdiRp8MvURV/qcWsd/FY=; b=YuAreBaUQPYHNY6iWi0swk9EyZkBf4WIa40wIRgoM3tLqX04JIMp72hjIz7WI+GFRI 3SPYzzajsvntjpw5b8aGah79ENoxXmEb70aqLGnAnfAtbGPy/vsFTBakj4nghRtqoX/w g+rUymBlDex/cvJ5yswAxRXYffms6kJMEZpGNV75H5uG3YuFnktN+KtjY4SKj8XzzuyV GzUvG2CAFv1Y2T7hKpStVTl3vTf0MgpaoPiQ8hi2PV0sdbuMpwpUkayf3MTyzF5KEk7A j4KHsm1+KRE1yCscHVtGMGuFkS/tClDAeeHG8xUdcYLhWZon9x6hJzbevLE41WFq+c6H cgmw== X-Gm-Message-State: ALoCoQlfohDv3PstQCxMRjV2FjGSCiMEr2W9S5EcKZ6KaLNmTcG4kTuvy1ZtopfnO4tSo7AvVjVp X-Received: by 10.194.109.201 with SMTP id hu9mr15559961wjb.45.1418296568211; Thu, 11 Dec 2014 03:16:08 -0800 (PST) Received: from [10.16.0.195] (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by mx.google.com with ESMTPSA id cz3sm1267945wjb.23.2014.12.11.03.16.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Dec 2014 03:16:07 -0800 (PST) Message-ID: <54897CF6.2020509@6wind.com> Date: Thu, 11 Dec 2014 12:16:06 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: "Zhang, Helin" , Thomas Monjalon References: <1417829617-7185-1-git-send-email-helin.zhang@intel.com> <2233989.0bm00NiAWz@xps13> <17296025.Gs0n2xkUhX@xps13> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 11 Dec 2014 11:16:08 -0000 Hi Helin, On 12/10/2014 11:29 PM, Zhang, Helin wrote: >>>>> --- 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 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, it always treats > it as a general IP packet. The "inner" IP is just part of its data. For this case, no outer > or inner at all, just an IP header. > >> >> 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. I still don't understand how to use that flag. Let's imagine an application that processes an IP packet: ip_input(m) /* receive a packet after ethernet header is stripped */ { if (m->ol_flags & PKT_RX_IP_CKSUM_BAD) { log("packet dropped"); rte_pktmbuf_free(m); return; } /* continue IP header processing,maybe route the packet? */ ... This kind of code works since a long time with dpdk on ixgbe, even if you receive a tunnel packet. In my understanding, with your patch, if you receive a tunnel packet on i40e, the flag PKT_RX_IP_CKSUM_BAD is about the inner header, which should not be checked by a router. This would make the code above not working anymore. Am I correct? By the way (it's a bit out of topic), as we already noticed on the list some times, in the future we should add another flags PKT_RX_IP_CKSUM_VERIFIED in addition to PKT_RX_IP_CKSUM_BAD because many drivers do not support hardware checksum, or only supports it in specific conditions (ex: no IP options, or no vlan, ...). We should think about it for 2.0. Regards, Olivier