From: "Yang, Qiming" <qiming.yang@intel.com>
To: Andrew Rybchenko <arybchenko@solarflare.com>,
Adrien Mazarguil <adrien.mazarguil@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC] New packet type query API
Date: Tue, 23 Jan 2018 02:46:59 +0000 [thread overview]
Message-ID: <F5DF4F0E3AFEF648ADC1C3C33AD4DBF16F828A9A@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <829b2bae-3a48-85d0-93ee-e6486726a575@solarflare.com>
Answered in adrien’s email.
From: Andrew Rybchenko [mailto:arybchenko@solarflare.com]
Sent: Wednesday, January 17, 2018 4:09 PM
To: Adrien Mazarguil <adrien.mazarguil@6wind.com>; Yang, Qiming <qiming.yang@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [RFC] New packet type query API
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
next prev parent reply other threads:[~2018-01-23 2:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-11 16:04 Qiming Yang
2018-01-16 15:55 ` Adrien Mazarguil
2018-01-17 8:08 ` Andrew Rybchenko
2018-01-17 14:34 ` Shahaf Shuler
2018-01-23 2:48 ` Yang, Qiming
2018-01-23 2:46 ` Yang, Qiming [this message]
2018-01-23 2:46 ` Yang, Qiming
2018-02-05 19:29 ` Adrien Mazarguil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F5DF4F0E3AFEF648ADC1C3C33AD4DBF16F828A9A@SHSMSX101.ccr.corp.intel.com \
--to=qiming.yang@intel.com \
--cc=adrien.mazarguil@6wind.com \
--cc=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).