From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Subject: Re: [PATCH] examples/l3fwd: fix using packet type blindly
Date: Tue, 1 Mar 2016 14:30:17 +0000
Message-ID: <2601191342CEEE43887BDE71AB97725836B0C9EF@irsmsx105.ger.corp.intel.com>
References: <1451544799-70776-1-git-send-email-jianfeng.tan@intel.com>
 <1456795416-118189-1-git-send-email-jianfeng.tan@intel.com>
 <2601191342CEEE43887BDE71AB97725836B0C99C@irsmsx105.ger.corp.intel.com>
 <56D5A476.6070500@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
To: "Tan, Jianfeng" <jianfeng.tan@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Return-path: <dev-bounces@dpdk.org>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
 by dpdk.org (Postfix) with ESMTP id 78CDB9AA6
 for <dev@dpdk.org>; Tue,  1 Mar 2016 15:31:43 +0100 (CET)
In-Reply-To: <56D5A476.6070500@intel.com>
Content-Language: en-US
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>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

> >> +
> >> +void
> >> +lpm_parse_ptype(struct rte_mbuf *m)
> >> +{
> >> +	struct ether_hdr *eth_hdr;
> >> +	uint32_t packet_type =3D 0;
> >> +	uint16_t ethertype;
> >> +
> >> +	eth_hdr =3D rte_pktmbuf_mtod(m, struct ether_hdr *);
> >> +	ethertype =3D rte_be_to_cpu_16(eth_hdr->ether_type);
> >> +	switch (ethertype) {
> >> +	case ETHER_TYPE_IPv4:
> >> +		packet_type |=3D RTE_PTYPE_L3_IPV4_EXT_UNKNOWN;
> >> +		break;
> >> +	case ETHER_TYPE_IPv6:
> >> +		packet_type |=3D RTE_PTYPE_L3_IPV6_EXT_UNKNOWN;
> >> +		break;
> >> +	default:
> >> +		break;
> >> +	}
> >> +
> >> +	m->packet_type |=3D packet_type;
> > Might be safer:
> > m->packet_type =3D packet_type;
>=20
> Your previous comment on this says that the assignment will write off
> some ptype info PMDs have filled. But for l3fwd, I think it does not
> care other ptype info.

Ah, yes - missed that you setup it to 0 at the start of that function.
Probably better than to use PTYPE_UNKNOW macro=20

>=20
> [...]
> > +static uint16_t
> > +cb_parse_packet_type(uint8_t port __rte_unused,
> > +		     uint16_t queue __rte_unused,
> > +		     struct rte_mbuf *pkts[],
> > +		     uint16_t nb_pkts,
> > +		     uint16_t max_pkts __rte_unused,
> > +		     void *user_param __rte_unused)
> > +{
> > +	unsigned i;
> > +
> > +	for (i =3D 0; i < nb_pkts; ++i)
> > +		l3fwd_lkp.parse_ptype(pkts[i]);
> >
> > No need to create callback chains.
> > That way you have extra call per packet.
> > Just 2 callbaclks: cb_lpm_parse_ptype & cb_em_parse_ptype,
> > and then register one depending on which mode are we in.
> > Would be simpler and faster, I believe.
>=20
> Yes, I was considering it too. In addition, shall I use vector
> instruction here to accelerate it?

If you like you can have 2 versions one scalar one, another vector one.
Same as we have for the rest of EM/LPM processing.
Just scalar one would do too, at least for now.

Konstantin