[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