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

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

> -----Original Message-----
> From: Liu, Jijiang
> Sent: Wednesday, November 19, 2014 3:53 AM
> To: Ananyev, Konstantin
> Cc: dev@dpdk.org; Richardson, Bruce
> Subject: RE: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> 
> 
> 
> > -----Original Message-----
> > From: Ananyev, Konstantin
> > Sent: Tuesday, November 18, 2014 11:29 PM
> > To: Richardson, Bruce
> > Cc: Liu, Jijiang; dev@dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> >
> >
> >
> > > -----Original Message-----
> > > From: Richardson, Bruce
> > > Sent: Tuesday, November 18, 2014 1:08 PM
> > > To: Ananyev, Konstantin
> > > Cc: Liu, Jijiang; dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> > >
> > > On Tue, Nov 18, 2014 at 11:33:24AM +0000, Ananyev, Konstantin wrote:
> > > > 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.
> > > > 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;
> 
> In current codes, the mbuf->packet_type  = 0 has already  been done in rte_pktmbuf_reset().

Ok yes, I missed that: indeed we already do mbuf->packet_type  = 0 in rte_pktmbuf_reset().
Though, as I said in another mail our PMDs RX routines don't use rte_pktmbuf_reset() for performance reasons.
So, I still think that scalar ixgbe, igb/em and virtio/vmnext3 need to be updated. 

> 
> > > > 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?
> > > >
> > > Add a RTE_PTYPE_MAX value = UINT16_MAX to the enum, perhaps?
> >
> > Yep, add something like RTE_PTYPE_MAX  = UINT16_MAX and RTE_PTYPE_MIN
> > == 0 seems like a good thing to me too.
> 
> Ok,  will add RTE_PTYPE_MAX  = UINT16_MAX into rte_eth_packet_type.
> Currently,  RTE_PTYPE_UNDEF is 0, if the RTE_PTYPE_MIN needed, and RTE_PTYPE_MIN = 1, but I think it is not necessary  to add
> RTE_PTYPE_MIN.

Why you need to setup RTE_PTYPE_MIN == 1?
Why it can't be done like that:

enum rte_eth_ptype { 
   RTE_PTYPE_MIN = 0,
   RTE_PTYPE_UDEF = RTE_PTYPE_MIN,
   ....
   RTE_PTYPE_MAX = UINT16_MAX
};
?

> 
> Moreover, there won't  be an icc compilation error for the following codes, so we can set mb-> packet_type  using enum paket_type
> directly in i40e driver.
> enum rte_eth_packet_type  paket_type;
> mb-> packet_type  =  paket_type;    //packet_type is uint16 in mbuf.
> 
> But there will be an icc compilation error for the following codes, we must convert packet_type in mbuf .
> enum rte_eth_packet_type paket_type;
> paket_type = mb-> packet_type ;    //packet_type is uint16 in mbuf.
> 
> and it needs to change as follows to avoid compilation error using icc.
> paket_type =(rte_eth_packet_type)  mb-> packet_type;

Not sure I understand you here.
I think you'll still need to do a direct conversion to keep old versions of icc happy:

mb-> packet_type  =  (uint16_t)paket_type;
...
paket_type =(rte_eth_packet_type) mb-> packet_type;    

> 
> >
> > >
> > > /Bruce