Hi Konstantin,

On 1/15/2016 10:47 PM, Ananyev, Konstantin wrote:

Hi Jianfeng,

quoted

-----Original Message-----
From: Tan, Jianfeng
Sent: Friday, January 15, 2016 5:46 AM
To: dev@dpdk.org
Cc: Zhang, Helin; Ananyev, Konstantin; Tan, Jianfeng
Subject: [PATCH v2 12/12] examples/l3fwd: add option to parse ptype

As a example to use ptype info, l3fwd needs firstly to use
rte_eth_dev_get_ptype_info() API to check if device and/or PMD driver will
parse and fill the needed packet type. If not, use the newly added option,
--parse-ptype, to analyze it in the callback softly.

Signed-off-by: Jianfeng Tan <redacted>
---
  examples/l3fwd/main.c | 91 +++++++++++++++++++++++++++++++++++++++++++++++++++
  1 file changed, 91 insertions(+)

...

quoted

+static inline void
+parse_packet_type(struct rte_mbuf *m)
+{
+	struct ether_hdr *eth_hdr;
+	uint32_t packet_type = 0;
+	uint16_t ethertype;
+
+	eth_hdr = rte_pktmbuf_mtod(m, struct ether_hdr *);
+	ethertype = rte_be_to_cpu_16(eth_hdr->ether_type);
+	switch (ethertype) {
+	case ETHER_TYPE_IPv4:
+		packet_type |= RTE_PTYPE_L3_IPV4_EXT_UNKNOWN;
+		break;
+	case ETHER_TYPE_IPv6:
+		packet_type |= RTE_PTYPE_L3_IPV6_EXT_UNKNOWN;
+		break;

That's enough for LPM, for EM, don't we need to be sure there are no extensions
in the IP header?

Konstantin

Yes, EM needs to differentiate RTE_PTYPE_L3_IPV4/RTE_PTYPE_L3_IPV4_EXT, 
RTE_PTYPE_L3_IPV6/RTE_PTYPE_L3_IPV6_EXT:
a. for soft ptype parser here, I'll add the code to do it.

b. for hardware ptype parser, things become complex:
those NICs which can differentiate:
e1000
fmf10k
ixgbe
those NICs which cannot differentiate:
cxgbe (ipv4, ipv6)
enic (ipv4, ipv6)
i40e (ipv4_ext_unknown, ipv6_ext_unknown)
mlx4 (ipv4, ipv6)
mlx5 (ipv4, ipv6)
nfp (ipv4, ipv6, ipv6_ext)
vmxnet3 (ipv4, ipv4_ext)

As a result, l3fwd can only work perfectly on those NICs which can 
differentiate.

SO if we really do the strict checking?

Thanks,
Jianfeng