From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <jijiang.liu@intel.com>
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24])
by dpdk.org (Postfix) with ESMTP id ED2EF5948
for <dev@dpdk.org>; Wed, 22 Oct 2014 03:39:24 +0200 (CEST)
Received: from orsmga002.jf.intel.com ([10.7.209.21])
by orsmga102.jf.intel.com with ESMTP; 21 Oct 2014 18:46:36 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,766,1406617200"; d="scan'208";a="622895255"
Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78])
by orsmga002.jf.intel.com with ESMTP; 21 Oct 2014 18:47:40 -0700
Received: from kmsmsx152.gar.corp.intel.com (172.21.73.87) by
PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server (TLS)
id 14.3.195.1; Wed, 22 Oct 2014 09:47:00 +0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by
KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server (TLS)
id 14.3.195.1; Wed, 22 Oct 2014 09:47:00 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by
SHSMSX103.ccr.corp.intel.com ([169.254.4.207]) with mapi id 14.03.0195.001;
Wed, 22 Oct 2014 09:46:59 +0800
From: "Liu, Jijiang" <jijiang.liu@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Thread-Topic: [dpdk-dev] [PATCH v6 2/9] librte_ether:add VxLAN packet
identification API in librte_ether
Thread-Index: AQHP7Rz/36CcrBji70yGvoQoDSEZtJw6h8/AgAABQICAAMTQYA==
Date: Wed, 22 Oct 2014 01:46:58 +0000
Message-ID: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D827A2@SHSMSX101.ccr.corp.intel.com>
References: <1413881168-20239-1-git-send-email-jijiang.liu@intel.com>
<3607443.z2coKxdkI7@xps13>
<1ED644BD7E0A5F4091CF203DAFB8E4CC01D82530@SHSMSX101.ccr.corp.intel.com>
<282785858.Uoneh1Nj8l@xps13>
In-Reply-To: <282785858.Uoneh1Nj8l@xps13>
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="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v6 2/9] librte_ether:add VxLAN packet
identification API in librte_ether
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Oct 2014 01:39:25 -0000
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Wednesday, October 22, 2014 5:19 AM
> To: Liu, Jijiang
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v6 2/9] librte_ether:add VxLAN packet
> identification API in librte_ether
>=20
> 2014-10-21 13:48, Liu, Jijiang:
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > 2014-10-21 16:46, Jijiang Liu:
> > > > int
> > > > +rte_eth_dev_udp_tunnel_add(uint8_t port_id,
> > > > + struct rte_eth_udp_tunnel *udp_tunnel,
> > > > + uint8_t count)
> > > > +{
> > > > + uint8_t i;
> > > > + struct rte_eth_dev *dev;
> > > > + struct rte_eth_udp_tunnel *tunnel;
> > > > +
> > > > + if (port_id >=3D nb_ports) {
> > > > + PMD_DEBUG_TRACE("Invalid port_id=3D%d\n", port_id);
> > > > + return -ENODEV;
> > > > + }
> > > > +
> > > > + if (udp_tunnel =3D=3D NULL) {
> > > > + PMD_DEBUG_TRACE("Invalid udp_tunnel parameter\n");
> > > > + return -EINVAL;
> > > > + }
> > > > + tunnel =3D udp_tunnel;
> > > > +
> > > > + for (i =3D 0; i < count; i++, tunnel++) {
> > > > + if (tunnel->prot_type >=3D RTE_TUNNEL_TYPE_MAX) {
> > > > + PMD_DEBUG_TRACE("Invalid tunnel type\n");
> > > > + return -EINVAL;
> > > > + }
> > > > + }
> > >
> > > I'm not sure it's a good idea to provide a count parameter to
> > > iterate in a loop.
> > > It's probably something that the application should do by itself.
> >
> > It is necessary to check if this prot_type(tunnel type) is valid here
> > in case applications don't do that.
>=20
> Yes, you have to check prot_type but looping for several tunnels is not
> needed at this level.
>=20
> > > But I doubt we should configure a tunnel type for a whole port.
> >
> > Yes, your understanding is correct. It is for a whole port/PF, that's
> > why we should add tunnel_type in rte_eth_conf structure.
>=20
> Please explain me why a tunnel type should be associated to a port.
> This design looks really broken.
I don't think this design looks really broken.
Currently, A PF associated to a port, right? What tunnel type should be su=
pported in a PF, which is required we configure it.
Tunneling packet is encapsulation packet, in terms of VxLAN, packet format =
is outer L2 header+ outer L3 header +outer L4 header + tunneling header+ in=
ner L2 header + inner L3 header + inner L4 header +PAY4.
For a VM/VF, the real useful packet data is "inner L2 header + inner L3 he=
ader + inner L4 header +PAY4". =20
In NIC, A port/PF receive this kind of tunneling packet(outer L2+...PAY4), =
software should be responsible for decapsulating the packet and deliver re=
al data(innerL2 + PAY4) to VM/VF=1B$B!#=1B(B
DPDK just provide API/mechanism to guarantee a PF/port to receive the tunne=
ling packet data, the encapsulation/ decapsulation work should be done by u=
ser application.
Normally, the tunneling packet processing like below:
Tunneling packet ------>PF processing/receive ---------> application SW do =
decapsulation -------> VF/VM processing
> Thanks
> --
> Thomas