Re: [dpdk-dev] [PATCH v4 2/8]i40e:support VxLAN packet identification in librte_pmd_i40e

["Liu, Jijiang" <jijiang.liu@intel.com>]

Hi Bruce,

> -----Original Message-----
> From: Richardson, Bruce
> Sent: Monday, September 29, 2014 6:48 PM
> To: Liu, Jijiang
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4 2/8]i40e:support VxLAN packet
> identification in librte_pmd_i40e
> 
> On Fri, Sep 26, 2014 at 10:02:03AM +0800, Jijiang Liu wrote:
> > Support tunneling UDP port configuration on i40e in librte_pmd_i40e.
> > Currently, only VxLAN is implemented, which include
> >  -  VxLAN UDP port initialization
> >  -  Implement the APIs to configure VxLAN UDP port in librte_pmd_i40e.
> >
> > Signed-off-by: Jijiang Liu <jijiang.liu@intel.com>
> > Acked-by: Helin Zhang <helin.zhang@intel.com>
> > Acked-by: Jingjing Wu <jingjing.wu@intel.com>
> > Acked-by: Jing Chen <jing.d.chen@intel.com>
> >
> > ---
> >  config/common_linuxapp            |    5 +
> >  lib/librte_mbuf/rte_mbuf.h        |    2 +
> >  lib/librte_pmd_i40e/i40e_ethdev.c |  200
> ++++++++++++++++++++++++++++++++++++-
> >  lib/librte_pmd_i40e/i40e_ethdev.h |    5 +
> >  lib/librte_pmd_i40e/i40e_rxtx.c   |   10 ++
> >  5 files changed, 221 insertions(+), 1 deletions(-)
> >
> > diff --git a/config/common_linuxapp b/config/common_linuxapp index
> > 5bee910..75a4cd7 100644
> > --- a/config/common_linuxapp
> > +++ b/config/common_linuxapp
> > @@ -212,6 +212,11 @@
> CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
> >  CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL=-1
> >
> >  #
> > +# Compile tunneling UDP port support
> > +#
> > +CONFIG_RTE_LIBRTE_TUNNEL_UDP_PORT=4789
> > +
> > +#
> >  # Compile burst-oriented VIRTIO PMD driver  #
> > CONFIG_RTE_LIBRTE_VIRTIO_PMD=y diff --git a/lib/librte_mbuf/rte_mbuf.h
> > b/lib/librte_mbuf/rte_mbuf.h index 1c6e115..4955684 100644
> > --- a/lib/librte_mbuf/rte_mbuf.h
> > +++ b/lib/librte_mbuf/rte_mbuf.h
> > @@ -538,6 +538,7 @@ static inline void rte_pktmbuf_reset(struct rte_mbuf
> *m)
> >  	m->port = 0xff;
> >
> >  	m->ol_flags = 0;
> > +	m->reserved = 0;
> >  	m->data_off = (RTE_PKTMBUF_HEADROOM <= m->buf_len) ?
> >  			RTE_PKTMBUF_HEADROOM : m->buf_len;
> >
> > @@ -607,6 +608,7 @@ static inline void rte_pktmbuf_attach(struct
> rte_mbuf *mi, struct rte_mbuf *md)
> >  	mi->pkt_len = mi->data_len;
> >  	mi->nb_segs = 1;
> >  	mi->ol_flags = md->ol_flags;
> > +	mi->reserved = md->reserved;
> >
> >  	__rte_mbuf_sanity_check(mi, 1);
> >  	__rte_mbuf_sanity_check(md, 0);
> 
> If the "reserved" field in the mbuf is now being used, it should be renamed to
> what its actually being used for. If it is still not being used, why this change?
> 
> /Bruce

As I said in the cover letter, when your Mbuf Structure Rework(part 3) is applied, there will be minor changes later.
I will not keep the current changes in mbuf part, and rename the "reserved2" field to the "packet_type" in rte_mbuf structure instead.
Tunneling application need to know what packet type of incoming packet is. 

/Jijiang Liu