[dpdk-dev] [PATCH v2] examples/l3fwd: fix using packet type blindly

Tan, Jianfeng jianfeng.tan at intel.com
Tue Mar 8 18:11:18 CET 2016


Hi Konstantin,

On 3/8/2016 2:51 AM, Ananyev, Konstantin wrote:
> Hi Jianfeng,
>
>> +/* Requirements:
>> + * 1. IP packets without extension;
>> + * 2. L4 payload should be either TCP or UDP.
>> + */
>> +int
>> +em_check_ptype(int portid)
>> +{
>> +	int i, ret;
>> +	int ptype_l3_ipv4_ext = 0;
>> +	int ptype_l3_ipv6_ext = 0;
>> +	int ptype_l4_tcp = 0;
>> +	int ptype_l4_udp = 0;
>> +
>> +	ret = rte_eth_dev_get_ptype_info(portid,
>> +					 RTE_PTYPE_L3_MASK | RTE_PTYPE_L4_MASK,
>> +					 NULL, 0);
>> +	if (ret <= 0)
>> +		return 0;
>> +
>> +	uint32_t ptypes[ret];
>> +
>> +	ret = rte_eth_dev_get_ptype_info(portid,
>> +					 RTE_PTYPE_L3_MASK | RTE_PTYPE_L4_MASK,
>> +					 ptypes, ret);
>> +	for (i = 0; i < ret; ++i) {
>> +		switch (ptypes[i]) {
>> +		case RTE_PTYPE_L3_IPV4_EXT:
>> +			ptype_l3_ipv4_ext = 1;
>> +			break;
>> +		case RTE_PTYPE_L3_IPV6_EXT:
>> +			ptype_l3_ipv6_ext = 1;
>> +			break;
>> +		case RTE_PTYPE_L4_TCP:
>> +			ptype_l4_tcp = 1;
>> +			break;
>> +		case RTE_PTYPE_L4_UDP:
>> +			ptype_l4_udp = 1;
>> +			break;
>> +		}
>> +	}
>> +
>> +	if (ptype_l3_ipv4_ext == 0)
>> +		printf("port %d cannot parse RTE_PTYPE_L3_IPV4_EXT\n", portid);
>> +	if (ptype_l3_ipv6_ext == 0)
>> +		printf("port %d cannot parse RTE_PTYPE_L3_IPV6_EXT\n", portid);
>> +	if (!ptype_l3_ipv4_ext || !ptype_l3_ipv6_ext)
>> +		return 0;
>> +
>> +	if (ptype_l4_tcp == 0)
>> +		printf("port %d cannot parse RTE_PTYPE_L4_TCP\n", portid);
>> +	if (ptype_l4_udp == 0)
>> +		printf("port %d cannot parse RTE_PTYPE_L4_UDP\n", portid);
>> +	if (ptype_l4_tcp || ptype_l4_udp)
>> +		return 1;
> Should probably be: if (ptype_l4_tcp && ptype_l4_udp)
> ?

Oops, yes, we need to make it as a strict checking here.

>
>> +
>> +	return 0;
>> +}
>> +
>> +static inline void
>> +em_parse_ptype(struct rte_mbuf *m)
>> +{
>> +	struct ether_hdr *eth_hdr;
>> +	uint32_t packet_type = RTE_PTYPE_UNKNOWN;
>> +	uint16_t ethertype;
>> +	void *l3;
>> +	int hdr_len;
>> +	struct ipv4_hdr *ipv4_hdr;
>> +	struct ipv6_hdr *ipv6_hdr;
>> +
>> +	eth_hdr = rte_pktmbuf_mtod(m, struct ether_hdr *);
>> +	ethertype = rte_be_to_cpu_16(eth_hdr->ether_type);
> I think you can avoid bswap here, if use constants in BE format
> for comparison instead:
>   
> ethertype = eth_hdr->ether_type;
> switch (ethertype) {
> case (rte_cpu_to_be_16(ETHER_TYPE_IPv4)):
> ...
>
> Same for lpm.

Great advice!

>
>> @@ -612,6 +622,14 @@ parse_args(int argc, char **argv)
>>   					return -1;
>>   				}
>>   			}
>> +
>> +			if (!strncmp(lgopts[option_index].name,
>> +				     CMD_LINE_OPT_PARSE_PTYPE,
>> +				     sizeof(CMD_LINE_OPT_PARSE_PTYPE))) {
>> +				printf("soft parse-ptype is enabled\n");
>> +				parse_ptype = 1;
>> +			}
>> +
>>   			break;
>>
>>   		default:
>> @@ -965,6 +983,40 @@ main(int argc, char **argv)
>>   			rte_eth_promiscuous_enable(portid);
>>   	}
>>
>> +	printf("\n");
>> +
>> +	for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
>> +		if (rte_lcore_is_enabled(lcore_id) == 0)
>> +			continue;
>> +		qconf = &lcore_conf[lcore_id];
>> +		for (queue = 0; queue < qconf->n_rx_queue; ++queue) {
>> +			portid = qconf->rx_queue_list[queue].port_id;
>> +			queueid = qconf->rx_queue_list[queue].queue_id;
>> +
>> +			ret = l3fwd_lkp.check_ptype(portid);
>> +			if (ret) {
>> +				printf("Port %d: built-in packet type info\n",
>> +				       portid);
>> +				continue;
>> +			}
>
> I thought that if parse_ptype != 0 we always want to use a SW parsing,
> no matter does HW support it or not, no?

Thanks for pointing this out. It's actually worth discussion. It depends 
on how --parse-ptype option means:
a. try best to use hw way, if fails, turns to sw way;
b. use sw way no matter hw way is workable.

Way a makes it portable to use the same cmd line of l3fwd for all devices.
Way b makes it more clear for this option.

I am actually more inclined to way b (your suggested way).

> So user can measure what is the performance difference between HW and SW versions?
> Another thing, that I forgot to ask earlier - with ptype querying in place, would we like to set:
> RTE_I40E_INC_VECTOR=y
> by default?

Thoughtful! I think you are right, and I'll double check with Tao Zhe.

Thanks,
Jianfeng

>
> Konstantin



More information about the dev mailing list