[dpdk-dev] [PATCH 0/4] Translate packet types for i40e

[Zhang, Helin]

> -----Original Message-----
> From: Ananyev, Konstantin
> Sent: Tuesday, November 18, 2014 11:26 PM
> To: Zhang, Helin; Liu, Jijiang; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> 
> 
> 
> > -----Original Message-----
> > From: Zhang, Helin
> > Sent: Tuesday, November 18, 2014 2:12 PM
> > To: Ananyev, Konstantin; Liu, Jijiang; dev at dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> >
> >
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ananyev,
> > > Konstantin
> > > Sent: Tuesday, November 18, 2014 7:33 PM
> > > To: Liu, Jijiang; dev at dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> > >
> > > Hi Frank,
> > >
> > > > -----Original Message-----
> > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu
> > > > Sent: Tuesday, November 18, 2014 7:37 AM
> > > > To: dev at 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?
So mbuf header fields are not zero-ed by default? That might not be what I guessed.

> 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