From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <olivier.matz@6wind.com>
Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49])
 by dpdk.org (Postfix) with ESMTP id E5E213975
 for <dev@dpdk.org>; Tue, 25 Nov 2014 13:27:00 +0100 (CET)
Received: by mail-wg0-f49.google.com with SMTP id x12so729286wgg.8
 for <dev@dpdk.org>; Tue, 25 Nov 2014 04:37:53 -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=OktQYMu2VPXxupx3qXS6KSa+KNGHhSDdzQ2uZuWESw8=;
 b=M5xc38B11gLfWXzHSSV5MuqJj9q8Y72AONbXhhE8VCMdCmY5gkLAoJP7N4v7fzXZRb
 0+Y0z92CsIkSgnMsoT5dYTpXZAnVw5LvLV3oyJgFSfPUEfS8lygsZjw8hDTiDEImpyGT
 JONi/0we5Y0906QqRV1pjwduV6X85lZTNF3XPoJ/n5c+YqGHi7jwxOpXRNPlgEx/CxSm
 yJu5D0m/zNh5j5lLjXFRbx0lRMxMJRcgk8itHb+5UdnP/qp2hrOExpDOxUBzZ3xoxj7q
 asn3lNXBe6TSt0ui6+IAuy0ymryBm80BKvZExErYXzFNYKPvxe4ZgjiTqeWYHCJMhqTl
 76aQ==
X-Gm-Message-State: ALoCoQkO6jpWQZbCHINpR/hG7yGJR1jvSF8KzNBRcwLu/QUym7JN/nDDkqK7w2zICswg9xTRVmKo
X-Received: by 10.180.83.105 with SMTP id p9mr25522018wiy.49.1416919073095;
 Tue, 25 Nov 2014 04:37:53 -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 td9sm2653149wic.15.2014.11.25.04.37.52
 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Tue, 25 Nov 2014 04:37:52 -0800 (PST)
Message-ID: <5474781F.6040501@6wind.com>
Date: Tue, 25 Nov 2014 13:37:51 +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>, 
 "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
 "'dev@dpdk.org'" <dev@dpdk.org>
References: <1415635166-1364-1-git-send-email-olivier.matz@6wind.com>
 <1415984609-2484-1-git-send-email-olivier.matz@6wind.com>
 <1415984609-2484-7-git-send-email-olivier.matz@6wind.com>
 <2601191342CEEE43887BDE71AB977258213AE5A1@IRSMSX105.ger.corp.intel.com>
 <546B1188.2090203@6wind.com>
 <2601191342CEEE43887BDE71AB977258213B6BDA@IRSMSX105.ger.corp.intel.com>
 <2601191342CEEE43887BDE71AB977258213B958A@IRSMSX105.ger.corp.intel.com>
 <F35DEAC7BCE34641BA9FAC6BCA4A12E70A7CAEA8@SHSMSX104.ccr.corp.intel.com>
In-Reply-To: <F35DEAC7BCE34641BA9FAC6BCA4A12E70A7CAEA8@SHSMSX104.ccr.corp.intel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "'jigsaw@gmail.com'" <jigsaw@gmail.com>
Subject: Re: [dpdk-dev] [PATCH v2 06/13] mbuf: add functions to get the name
 of	an ol_flag
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: Tue, 25 Nov 2014 12:27:01 -0000

Hi Helin,

On 11/25/2014 01:15 PM, Zhang, Helin wrote:
>>>> I would be in favor of removing them, or at least the following ones
>>>> (I don't understand how they can help the application):
>>>>
>>>> - PKT_RX_OVERSIZE: Num of desc of an RX pkt oversize.
>>>> - PKT_RX_HBUF_OVERFLOW: Header buffer overflow.
>>>> - PKT_RX_RECIP_ERR: Hardware processing error.
>>>> - PKT_RX_MAC_ERR: MAC error.
>>>
>>> Tend to agree...
>>> Or probably collapse these 4 flags into one: flag PKT_RX_ERR or something.
>>> Might be still used by someone for debugging purposes.
>>> Helin, what do you think?
>>
>> As there is no answer, I suppose you don't care these flags any more.
>> So we can just remove them, right?
> Sorry, I think I care it a bit. I have a lot of emails to be dealt with, due to the whole week training.
> Yes, it was added there before new mbuf defined. Why zero? Because of lack of bits for them.
> Unfortunately, I forgot to add them with correct values after new mbuf introduced.
> Thank you so much for spotting it out!
>
> The error flags were added according to the errors defined by FVL datasheet. It could be
> helpful for middle layer software or applications with the specific errors identified. I'd prefer
> to add the correct values for those flags. What do you think?

Could you elaborate about why it could be useful for an application
to have this flag in the mbuf? When these flags are set, is the data
still present in the mbuf? How can the application use this data if
the hardware says "there is an error in the packet"?

I think a stats counter would do the job here.

Regards,
Olivier