From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <olivier.matz@6wind.com>
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 <dev@dpdk.org>; Thu, 11 Dec 2014 12:16:08 +0100 (CET)
Received: by mail-wi0-f169.google.com with SMTP id r20so1092880wiv.4
for <dev@dpdk.org>; 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 <multiple recipients>
(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 <olivier.matz@6wind.com>
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" <helin.zhang@intel.com>,
Thomas Monjalon <thomas.monjalon@6wind.com>
References: <1417829617-7185-1-git-send-email-helin.zhang@intel.com>
<2233989.0bm00NiAWz@xps13>
<F35DEAC7BCE34641BA9FAC6BCA4A12E70A7D086F@SHSMSX104.ccr.corp.intel.com>
<17296025.Gs0n2xkUhX@xps13>
<F35DEAC7BCE34641BA9FAC6BCA4A12E70A7D0A78@SHSMSX104.ccr.corp.intel.com>
In-Reply-To: <F35DEAC7BCE34641BA9FAC6BCA4A12E70A7D0A78@SHSMSX104.ccr.corp.intel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "dev@dpdk.org" <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: 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