From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: "Zhang, Helin" <helin.zhang@intel.com>,
"Liu, Jijiang" <jijiang.liu@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
Date: Tue, 18 Nov 2014 15:26:03 +0000 [thread overview]
Message-ID: <2601191342CEEE43887BDE71AB977258213B58B9@IRSMSX105.ger.corp.intel.com> (raw)
In-Reply-To: <F35DEAC7BCE34641BA9FAC6BCA4A12E70A7C8757@SHSMSX104.ccr.corp.intel.com>
> -----Original Message-----
> From: Zhang, Helin
> Sent: Tuesday, November 18, 2014 2:12 PM
> To: Ananyev, Konstantin; Liu, Jijiang; dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
>
>
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev, Konstantin
> > Sent: Tuesday, November 18, 2014 7:33 PM
> > To: Liu, Jijiang; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> >
> > Hi Frank,
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jijiang Liu
> > > Sent: Tuesday, November 18, 2014 7:37 AM
> > > To: dev@dpdk.org
> > > Subject: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> > >
> > > The i40e NIC can recognize many packet types, including ordinary L2
> > > packet format and tunneling packet format such as IP in IP, IP in GRE, MAC in
> > GRE and MAC in UDP.
> > >
> > > This patch set provides abstract definitions of packet types, which
> > > can help user to use these packet types directly in their applications to speed
> > up receive packet analysis.
> > >
> > > Moreover, this patch set translates i40e packet types to abstract
> > > packet types in i40e driver, and make the corresponding changes in test
> > applications.
> > >
> > > Jijiang Liu (4):
> > > Add packet type and IP header check in rte_mbuf
> > > Remove the PKT_RX_TUNNEL_IPV4_HDR and the
> > PKT_RX_TUNNEL_IPV6_HDR
> > > Translate i40e packet types
> > > Make the corresponding changes in test-pmd
> > >
> > > app/test-pmd/csumonly.c | 12 +-
> > > app/test-pmd/rxonly.c | 15 +-
> > > lib/librte_mbuf/rte_mbuf.h | 225 ++++++++++++++-
> > > lib/librte_pmd_i40e/i40e_rxtx.c | 604
> > > +++++++++++++++++++++------------------
> > > 4 files changed, 569 insertions(+), 287 deletions(-)
> > >
> >
> > The patch looks good to me in general.
> > Though I think it is not complete: we need to make sure that all PMDs RX
> > functions will set mbuf's packet_type to the defined value.
> We met quite a lot of similar situations, we designed a new way for i40e, then
> have to rework igb/ixgbe. E.g. configuring reta, flow director, etc.
> If possible, send the patch set as smaller as possible might be better. I guess
> igb/ixgbe will be done soon later.
>
> > As right now, only i40e implementation can distinguish packet_type properly, I
> > think all other PMDs for the freshly received packet should do:
> > mbuf->packet_type = RTE_PTYPE_UNDEF;
> If I am not wrong, RTE_PTYPE_UNDEF can be 0, is packet_type in mbuf initialized to 0?
Yes RTE_PTYPE_UNDEF == 0
> If yes, nothing needs to be done in igb/ixgbe for now.
Could you explain to me why is that?
As I remember none of our RX functions reset the whole mbuf to all zeroes.
None of them even call rte_pktmbuf_reset() for performance reasons.
So what/who would prevent reset packet_type of the freshly received packet_type to zero?
BTW, I think that rte_pktmbuf_reset() need to reset packet_type too.
>
> >
> > Another thing: right now mbuf's packet_type is uint16_t.
> > While enum rte_eth_packet_type will be interpreted by the compiler as 'int'
> > (32bits).
> > We can either change enum to a lot of defines (which I don't really like to do) or
> > probably just add a comment somewhere that enum rte_eth_packet_type
> > should never exceed UINT16_MAX value?
> >
> > Konstantin
> >
> > > --
> > > 1.7.7.6
>
> Regards,
> Helin
next prev parent reply other threads:[~2014-11-18 15:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-18 7:37 Jijiang Liu
2014-11-18 7:37 ` [dpdk-dev] [PATCH 1/4] rte_mbuf:add packet types Jijiang Liu
2014-11-19 10:38 ` Olivier MATZ
2014-11-21 12:26 ` Liu, Jijiang
2014-11-21 13:25 ` Olivier MATZ
2014-11-18 7:37 ` [dpdk-dev] [PATCH 2/4] rte_mbuf:remove tunneling IP offload flags Jijiang Liu
2014-11-18 7:37 ` [dpdk-dev] [PATCH 3/4] i40e:translate i40e packet types Jijiang Liu
2014-11-18 7:37 ` [dpdk-dev] [PATCH 4/4] testpmd:application changes Jijiang Liu
2014-11-18 11:33 ` [dpdk-dev] [PATCH 0/4] Translate packet types for i40e Ananyev, Konstantin
2014-11-18 13:08 ` Bruce Richardson
2014-11-18 15:29 ` Ananyev, Konstantin
2014-11-19 3:52 ` Liu, Jijiang
2014-11-19 9:47 ` Ananyev, Konstantin
2014-11-18 14:12 ` Zhang, Helin
2014-11-18 15:26 ` Ananyev, Konstantin [this message]
2014-11-18 15:55 ` Ananyev, Konstantin
2014-11-19 0:29 ` Zhang, Helin
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=2601191342CEEE43887BDE71AB977258213B58B9@IRSMSX105.ger.corp.intel.com \
--to=konstantin.ananyev@intel.com \
--cc=dev@dpdk.org \
--cc=helin.zhang@intel.com \
--cc=jijiang.liu@intel.com \
/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).