From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id B074E4C6E for ; Wed, 8 Oct 2014 05:36:53 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 07 Oct 2014 20:44:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,674,1406617200"; d="scan'208";a="611149547" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga002.fm.intel.com with ESMTP; 07 Oct 2014 20:44:06 -0700 Received: from fmsmsx157.amr.corp.intel.com (10.18.116.73) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 7 Oct 2014 20:44:06 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX157.amr.corp.intel.com (10.18.116.73) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 7 Oct 2014 20:44:06 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.203]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.172]) with mapi id 14.03.0195.001; Wed, 8 Oct 2014 11:44:04 +0800 From: "Liu, Jijiang" To: "Richardson, Bruce" Thread-Topic: [dpdk-dev] [PATCH v4 2/8]i40e:support VxLAN packet identification in librte_pmd_i40e Thread-Index: AQHP29LnLdhRwO7kSESsUsKgJPsOdpwlmW1Q Date: Wed, 8 Oct 2014 03:44:04 +0000 Message-ID: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D7532B@SHSMSX101.ccr.corp.intel.com> References: <1411696929-13856-1-git-send-email-jijiang.liu@intel.com> <1411696929-13856-3-git-send-email-jijiang.liu@intel.com> <20140929104824.GD12072@BRICHA3-MOBL> In-Reply-To: <20140929104824.GD12072@BRICHA3-MOBL> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v4 2/8]i40e:support VxLAN packet identification in librte_pmd_i40e X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 03:36:54 -0000 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 >=20 > 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 > > Acked-by: Helin Zhang > > Acked-by: Jingjing Wu > > Acked-by: Jing Chen > > > > --- > > 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=3D4 > > CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL=3D-1 > > > > # > > +# Compile tunneling UDP port support > > +# > > +CONFIG_RTE_LIBRTE_TUNNEL_UDP_PORT=3D4789 > > + > > +# > > # Compile burst-oriented VIRTIO PMD driver # > > CONFIG_RTE_LIBRTE_VIRTIO_PMD=3Dy 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_mbu= f > *m) > > m->port =3D 0xff; > > > > m->ol_flags =3D 0; > > + m->reserved =3D 0; > > m->data_off =3D (RTE_PKTMBUF_HEADROOM <=3D 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 =3D mi->data_len; > > mi->nb_segs =3D 1; > > mi->ol_flags =3D md->ol_flags; > > + mi->reserved =3D md->reserved; > > > > __rte_mbuf_sanity_check(mi, 1); > > __rte_mbuf_sanity_check(md, 0); >=20 > If the "reserved" field in the mbuf is now being used, it should be renam= ed to > what its actually being used for. If it is still not being used, why this= change? >=20 > /Bruce As I said in the cover letter, when your Mbuf Structure Rework(part 3) is a= pplied, 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.= =20 /Jijiang Liu