[dpdk-dev] [PATCH v4 2/8]i40e:support VxLAN packet identification in librte_pmd_i40e
Liu, Jijiang
jijiang.liu at intel.com
Wed Oct 8 05:44:04 CEST 2014
Hi Bruce,
> -----Original Message-----
> From: Richardson, Bruce
> Sent: Monday, September 29, 2014 6:48 PM
> To: Liu, Jijiang
> Cc: dev at 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 at intel.com>
> > Acked-by: Helin Zhang <helin.zhang at intel.com>
> > Acked-by: Jingjing Wu <jingjing.wu at intel.com>
> > Acked-by: Jing Chen <jing.d.chen at 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
More information about the dev
mailing list