From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Rybchenko <arybchenko@solarflare.com>
Subject: Re: [RFC] New packet type query API
Date: Wed, 17 Jan 2018 11:08:52 +0300
Message-ID: <829b2bae-3a48-85d0-93ee-e6486726a575@solarflare.com>
References: <20180111160405.182159-1-qiming.yang@intel.com>
 <20180116155532.GH4256@6wind.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Cc: <dev@dpdk.org>
To: Adrien Mazarguil <adrien.mazarguil@6wind.com>, Qiming Yang
 <qiming.yang@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com
 [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 967E744CF
 for <dev@dpdk.org>; Wed, 17 Jan 2018 09:09:00 +0100 (CET)
In-Reply-To: <20180116155532.GH4256@6wind.com>
Content-Language: en-GB
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://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: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On 01/16/2018 06:55 PM, Adrien Mazarguil wrote:
> I understand the motivation behind this proposal, however since new ideas
> must be challenged, I have a few comments:
>
> - How about making packet type recognition an optional offload configurable
>    per queue like any other (e.g. DEV_RX_OFFLOAD_PTYPE)? That way the extra
>    processing cost could be avoided for applications that do not care.
>
> - Depending on HW, packet type information inside RX descriptors may not
>    necessarily fit 64-bit, or at least not without transformation. This
>    transformation would still cause wasted cycles on the PMD side.
>
> - In case enable_ptype_direct is enabled, the PMD may not waste CPU cycles
>    but the subsequent look-up with the proposed API would translate to a
>    higher cost on the application side. As a data plane API, how does this
>    benefit applications that want to retrieve packet type information?
>
> - Without a dedicated mbuf flag, an application cannot tell whether enclosed
>    packet type data is in HW format. Even if present, if port information is
>    discarded or becomes invalid (e.g. mbuf stored in an application queue for
>    lengthy periods or passed as is to an unrelated application), there is no
>    way to make sense of the data.
>
> In my opinion, mbufs should only contain data fields in a standardized
> format. Managing packet types like an offload which can be toggled at will
> seems to be the best compromise. Thoughts?

+1