All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olivier MATZ <olivier.matz-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
To: "Zhang,
	Helin" <helin.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Cc: "dev-VfR2kkLFssw@public.gmane.org" <dev-VfR2kkLFssw@public.gmane.org>
Subject: Re: [RFC 01/17] mbuf: add definitions of unified packet types
Date: Tue, 20 Jan 2015 10:53:28 +0100	[thread overview]
Message-ID: <54BE2598.50608@6wind.com> (raw)
In-Reply-To: <F35DEAC7BCE34641BA9FAC6BCA4A12E70A7EB2A1-0J0gbvR4kTg/UvCtAeCM4rfspsVTdybXVpNB7YpNyf8@public.gmane.org>

Hi Helin,

On 01/20/2015 03:28 AM, Zhang, Helin wrote:
>> Another question I've asked several times[1][2] : what does having
>> RTE_PTYPE_TUNNEL_IP mean? What fields are checked by the hardware (or
>> the driver) and what fields should be checked by the application?
>> Are you sure that all the drivers (ixgbe, i40e, vmxnet3, enic) check the same
>> fields? (ethertype, ip version, ip len correct, ip checksum correct, flags, ...)
> RTE_PTYPE_TUNNEL_IP means hardware recognizes the received packet as an
> IP-in-IP packet.
> All the fields are filled by PMD which is recognized by hardware. The application
> can just use it which can save some cpu cycles to recognize the packet type by
> software.
> Drivers is responsible for filling with correct values according to the packet types
> recognized by its hardware. Different PMDs may fill with different values based on
> different capabilities.

Sorry, that does not answer to my question.

Let's take a simple example. Imagine a hardware-1 that is able to
recognize an IP packet by checking the ethertype and that the IP
version is set to 4.
Another hardware-2 recognize an IP packet by checking the ethertype,
the IP version and that the IP length is correct compared to m_len(m).

For the same packet, both hardwares will return RTE_PTYPE_L3_IPV4, but
they don't do the same checks on the packet. As I want my application
behave exactly the same whatever the hardware, I need to know what
checks are done in hardware, so I can decide what checks must be
done in my application.

Example of definition: RTE_PTYPE_L3_IPV4 means that ethertype is
0x0800 and IP.version is 4.

It means that I can skip these 2 tests in my application if I have
this packet_type, but all other checks must be done in software
(ip length, flags, checksum, ...)

For each packet type, we need a definition like above, and we must
check that all drivers setting a packet type behave like described.

Regards,
Olivier

  parent reply	other threads:[~2015-01-20  9:53 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-19  3:23 [RFC 00/17] unified packet type Helin Zhang
     [not found] ` <1421637803-17034-1-git-send-email-helin.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-01-19  3:23   ` [RFC 01/17] mbuf: add definitions of unified packet types Helin Zhang
     [not found]     ` <1421637803-17034-2-git-send-email-helin.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-01-19 16:19       ` Ananyev, Konstantin
     [not found]         ` <2601191342CEEE43887BDE71AB977258213DDE25-pww93C2UFcwu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-01-20  3:47           ` Zhang, Helin
2015-01-19 16:33       ` Neil Horman
     [not found]         ` <20150119163306.GD21790-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2015-01-19 17:27           ` Olivier MATZ
     [not found]             ` <54BD3E66.3040709-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
2015-01-19 18:15               ` Neil Horman
2015-01-20  2:28               ` Zhang, Helin
     [not found]                 ` <F35DEAC7BCE34641BA9FAC6BCA4A12E70A7EB2A1-0J0gbvR4kTg/UvCtAeCM4rfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-01-20  9:53                   ` Olivier MATZ [this message]
2015-01-19  3:23   ` [RFC 02/17] e1000: support of unified packet type Helin Zhang
2015-01-19  3:23   ` [RFC 03/17] ixgbe: " Helin Zhang
2015-01-19  3:23   ` [RFC 04/17] " Helin Zhang
2015-01-19  3:23   ` [RFC 05/17] i40e: " Helin Zhang
2015-01-19  3:23   ` [RFC 06/17] bond: " Helin Zhang
2015-01-19  3:23   ` [RFC 07/17] enic: " Helin Zhang
2015-01-19  3:23   ` [RFC 08/17] vmxnet3: " Helin Zhang
2015-01-19  3:23   ` [RFC 09/17] app/test-pipeline: " Helin Zhang
2015-01-19  3:23   ` [RFC 10/17] app/test-pmd: " Helin Zhang
2015-01-19  3:23   ` [RFC 11/17] app/test: " Helin Zhang
2015-01-19  3:23   ` [RFC 12/17] examples/ip_fragmentation: " Helin Zhang
2015-01-19  3:23   ` [RFC 13/17] examples/ip_reassembly: " Helin Zhang
2015-01-19  3:23   ` [RFC 14/17] examples/l3fwd-acl: " Helin Zhang
2015-01-19  3:23   ` [RFC 15/17] examples/l3fwd-power: " Helin Zhang
2015-01-19  3:23   ` [RFC 16/17] examples/l3fwd: " Helin Zhang
2015-01-19  3:23   ` [RFC 17/17] mbuf: remove old packet type bit masks for ol_flags Helin Zhang

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=54BE2598.50608@6wind.com \
    --to=olivier.matz-pdr9zngts4eavxtiumwx3w@public.gmane.org \
    --cc=dev-VfR2kkLFssw@public.gmane.org \
    --cc=helin.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.