Hi Konstantin,
On 1/15/2016 10:47 PM, Ananyev, Konstantin wrote:
> Hi Jianfeng,
>
>> -----Original Message-----
>> From: Tan, Jianfeng
>> Sent: Friday, January 15, 2016 5:46 AM
>> To: dev at 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 <jianfeng.tan at intel.com>
>> ---
>> examples/l3fwd/main.c | 91
>> +++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 91 insertions(+)
>>
...
>> +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
