From: Andrew Rybchenko <arybchenko@solarflare.com>
To: "Morten Brørup" <mb@smartsharesystems.com>,
"Stephen Hemminger" <stephen@networkplumber.org>,
"Rami Rosen" <roszenrami@gmail.com>
Cc: Thomas Monjalon <thomas@monjalon.net>, <dev@dpdk.org>,
<olivier.matz@6wind.com>, <ferruh.yigit@intel.com>
Subject: Re: [dpdk-dev] [RFC] function to parse packet headers
Date: Fri, 11 Jan 2019 11:28:45 +0300 [thread overview]
Message-ID: <dc26e122-c5a1-75b3-164a-b2bf9c021d8e@solarflare.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35B425C9@smartserver.smartshare.dk>
On 1/11/19 11:16 AM, Morten Brørup wrote:
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Andrew Rybchenko
>> On 1/11/19 3:11 AM, Stephen Hemminger wrote:
>>> All drivers that don't have hardware support for getting l2/l3 and
>>> ptype information should be calling rte_net_get_ptype() already.
>> Is it documented somewhere?
>>
> The drivers need to parse the packet headers to set MBUF->packet_type, and without hardware support for it, the alternative to calling rte_net_get_ptype() is implementing duplicate code in the driver.
I'm sorry, but I see it a bit different. The driver provides
rte_eth_dev_get_supported_ptypes().
If nothing is promised, nothing may be provided. If application needs
more ptypes, it can
call the library function and obtain required information. If
application does not need ptypes,
what the point to do ptype discovery in SW and through it away?
> In other words, you can interpret Stephen's "should be" as "would be silly if not". :-)
>
>
> Med venlig hilsen / kind regards
> - Morten Brørup
>
>
>
next prev parent reply other threads:[~2019-01-11 8:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-08 16:48 Morten Brørup
2019-01-08 20:09 ` Rami Rosen
2019-01-09 15:53 ` Morten Brørup
2019-01-09 23:57 ` Thomas Monjalon
2019-01-10 1:03 ` Rami Rosen
2019-01-11 0:11 ` Stephen Hemminger
2019-01-11 7:56 ` Andrew Rybchenko
2019-01-11 8:16 ` Morten Brørup
2019-01-11 8:28 ` Andrew Rybchenko [this message]
2019-01-11 8:35 ` Olivier Matz
2019-01-11 9:49 ` Ananyev, Konstantin
2019-01-11 12:04 ` Morten Brørup
2019-01-09 3:43 longtb5
2019-01-09 15:38 ` Morten Brørup
2019-01-10 3:25 ` longtb5
2019-01-10 8:21 ` Morten Brørup
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=dc26e122-c5a1-75b3-164a-b2bf9c021d8e@solarflare.com \
--to=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=mb@smartsharesystems.com \
--cc=olivier.matz@6wind.com \
--cc=roszenrami@gmail.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
/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).