?????????????? ???????? 1???? 2??????
wenhb at techsure.com.cn From: dev-request Date: 2016-03-13 23:17 To: dev Subject: dev Digest, Vol 83, Issue 176 Send dev mailing list submissions to dev at dpdk.org To subscribe or unsubscribe via the World Wide Web, visit http://dpdk.org/ml/listinfo/dev or, via email, send a message with subject or body 'help' to dev-request at dpdk.org You can reach the person managing the list at dev-owner at dpdk.org When replying, please edit your Subject line so it is more specific than "Re: Contents of dev digest..." Today's Topics: 1. Re: [PATCH v8 1/4] lib/ether: optimize struct rte_eth_tunnel_filter_conf (Thomas Monjalon) 2. Re: [PATCH v8 0/4] This patch set adds tunnel filter support for IP in GRE on i40e. (Thomas Monjalon) 3. dpdk hash lookup function crashed (segment fault) (??) 4. Re: [PATCH v4 0/4] Add PCAP support to source and sink port (Thomas Monjalon) 5. Re: [PATCH v3] ip_pipeline: add load balancing function to pass-through pipeline (Thomas Monjalon) 6. Re: [PATCH] app/test-pmd: add support for zero rx and tx queues (Thomas Monjalon) ---------------------------------------------------------------------- Message: 1 Date: Sun, 13 Mar 2016 13:01:05 +0100 From: Thomas Monjalon <thomas.monja...@6wind.com> To: Jingjing Wu <jingjing.wu at intel.com>, xutao.sun at intel.com Cc: dev at dpdk.org, helin.zhang at intel.com, Jijiang Liu <jijiang.liu at intel.com> Subject: Re: [dpdk-dev] [PATCH v8 1/4] lib/ether: optimize struct rte_eth_tunnel_filter_conf Message-ID: <3488408.ByHyY3dxP7 at xps13> Content-Type: text/plain; charset="us-ascii" 2016-03-10 11:05, Jingjing Wu: > From: Xutao Sun <xutao.sun at intel.com> > > Change the fields of outer_mac and inner_mac in struct > rte_eth_tunnel_filter_conf from pointer to struct in order to > keep the code's readability. It breaks compilation of examples/tep_termination. > --- a/app/test-pmd/cmdline.c > +++ b/app/test-pmd/cmdline.c > @@ -6628,8 +6628,10 @@ cmd_tunnel_filter_parsed(void *parsed_result, > struct rte_eth_tunnel_filter_conf tunnel_filter_conf; > int ret = 0; > > - tunnel_filter_conf.outer_mac = &res->outer_mac; > - tunnel_filter_conf.inner_mac = &res->inner_mac; > + rte_memcpy(&tunnel_filter_conf.outer_mac, &res->outer_mac, > + ETHER_ADDR_LEN); > + rte_memcpy(&tunnel_filter_conf.inner_mac, &res->inner_mac, > + ETHER_ADDR_LEN); Please use ether_addr_copy(). > --- a/drivers/net/i40e/i40e_ethdev.c > +++ b/drivers/net/i40e/i40e_ethdev.c > @@ -5839,10 +5839,10 @@ i40e_dev_tunnel_filter_set(struct i40e_pf *pf, > } > pfilter = cld_filter; > > - (void)rte_memcpy(&pfilter->outer_mac, tunnel_filter->outer_mac, > - sizeof(struct ether_addr)); > - (void)rte_memcpy(&pfilter->inner_mac, tunnel_filter->inner_mac, > - sizeof(struct ether_addr)); > + (void)rte_memcpy(&pfilter->outer_mac, &tunnel_filter->outer_mac, > + ETHER_ADDR_LEN); > + (void)rte_memcpy(&pfilter->inner_mac, &tunnel_filter->inner_mac, > + ETHER_ADDR_LEN); As already commented in January, please stop this useless return cast. There is a dedicated function to copy MAC addresses: ether_addr_copy() ------------------------------ Message: 2 Date: Sun, 13 Mar 2016 15:18:37 +0100 From: Thomas Monjalon <thomas.monja...@6wind.com> To: Jingjing Wu <jingjing.wu at intel.com>, xutao.sun at intel.com Cc: dev at dpdk.org, helin.zhang at intel.com Subject: Re: [dpdk-dev] [PATCH v8 0/4] This patch set adds tunnel filter support for IP in GRE on i40e. Message-ID: <2132081.GGHc1VANAT at xps13> Content-Type: text/plain; charset="us-ascii" 2016-03-10 11:05, Jingjing Wu: > Xutao Sun (4): > lib/ether: optimize the'rte_eth_tunnel_filter_conf' structure > lib/ether: add IP in GRE type > driver/i40e: implement tunnel filter for IP in GRE > app/test-pmd: test tunnel filter for IP in GRE I've done the changes for ether_addr_copy and fixed tep_termination. Applied, thanks ------------------------------ Message: 3 Date: Sun, 13 Mar 2016 22:38:14 +0800 (CST) From: ?? <zhang...@126.com> To: dev at dpdk.org Subject: [dpdk-dev] dpdk hash lookup function crashed (segment fault) Message-ID: <44245b2a.50bb.1537069ca54.Coremail.zhangwqh at 126.com> Content-Type: text/plain; charset=GBK Hi all, When I use the dpdk lookup function, I met the segment fault problem. Can anybody help to look at why this happens. I will put the aim what I want to do and the related piece of code, and my debug message, This problem is that in dpdk multi process - client and server example, dpdk-2.2.0/examples/multi_process/client_server_mp My aim is that server create a hash table, then share it to client. Client will write the hash table, server will read the hash table. I am using dpdk hash table. What I did is that server create a hash table (table and array entries), return the table address. I use memzone pass the table address to client. In client, the second lookup gets segment fault. The system gets crashed. I will put some related code here. create hash table function: struct onvm_ft* onvm_ft_create(int cnt, int entry_size) { struct rte_hash* hash; struct onvm_ft* ft; struct rte_hash_parameters ipv4_hash_params = { .name = NULL, .entries = cnt, .key_len = sizeof(struct onvm_ft_ipv4_5tuple), .hash_func = NULL, .hash_func_init_val = 0, }; char s[64]; /* create ipv4 hash table. use core number and cycle counter to get a unique name. */ ipv4_hash_params.name = s; ipv4_hash_params.socket_id = rte_socket_id(); snprintf(s, sizeof(s), "onvm_ft_%d-%"PRIu64, rte_lcore_id(), rte_get_tsc_cycles()); hash = rte_hash_create(&ipv4_hash_params); if (hash == NULL) { return NULL; } ft = (struct onvm_ft*)rte_calloc("table", 1, sizeof(struct onvm_ft), 0); if (ft == NULL) { rte_hash_free(hash); return NULL; } ft->hash = hash; ft->cnt = cnt; ft->entry_size = entry_size; /* Create data array for storing values */ ft->data = rte_calloc("entry", cnt, entry_size, 0); if (ft->data == NULL) { rte_hash_free(hash); rte_free(ft); return NULL; } return ft; } related structure: struct onvm_ft { struct rte_hash* hash; char* data; int cnt; int entry_size; }; in server side, I will call the create function, use memzone share it to client. The following is what I do: related variables: struct onvm_ft *sdn_ft; struct onvm_ft **sdn_ft_p; const struct rte_memzone *mz_ftp; sdn_ft = onvm_ft_create(1024, sizeof(struct onvm_flow_entry)); if(sdn_ft == NULL) { rte_exit(EXIT_FAILURE, "Unable to create flow table\n"); } mz_ftp = rte_memzone_reserve(MZ_FTP_INFO, sizeof(struct onvm_ft *), rte_socket_id(), NO_FLAGS); if (mz_ftp == NULL) { rte_exit(EXIT_FAILURE, "Canot reserve memory zone for flow table pointer\n"); } memset(mz_ftp->addr, 0, sizeof(struct onvm_ft *)); sdn_ft_p = mz_ftp->addr; *sdn_ft_p = sdn_ft; In client side: struct onvm_ft *sdn_ft; static void map_flow_table(void) { const struct rte_memzone *mz_ftp; struct onvm_ft **ftp; mz_ftp = rte_memzone_lookup(MZ_FTP_INFO); if (mz_ftp == NULL) rte_exit(EXIT_FAILURE, "Cannot get flow table pointer\n"); ftp = mz_ftp->addr; sdn_ft = *ftp; } The following is my debug message: I set a breakpoint in lookup table line. To narrow down the problem, I just send one flow. So the second time and the first time, the packets are the same. For the first time, it works. I print out the parameters: inside the onvm_ft_lookup function, if there is a related entry, it will return the address by flow_entry. Breakpoint 1, datapath_handle_read (dp=0x7ffff00008c0) at /home/zhangwei1984/openNetVM-master/openNetVM/examples/flow_table/sdn.c:191 191 ret = onvm_ft_lookup(sdn_ft, fk, (char**)&flow_entry); (gdb) print *sdn_ft $1 = {hash = 0x7fff32cce740, data = 0x7fff32cb0480 "", cnt = 1024, entry_size = 56} (gdb) print *fk $2 = {src_addr = 419496202, dst_addr = 453050634, src_port = 53764, dst_port = 11798, proto = 17 '\021'} (gdb) s onvm_ft_lookup (table=0x7fff32cbe4c0, key=0x7fff32b99d00, data=0x7ffff68d2b00) at /home/zhangwei1984/openNetVM-master/openNetVM/onvm/shared/onvm_flow_table.c:151 151 softrss = onvm_softrss(key); (gdb) n 152 printf("software rss %d\n", softrss); (gdb) software rss 403183624 154 tbl_index = rte_hash_lookup_with_hash(table->hash, (const void *)key, softrss); (gdb) print table->hash $3 = (struct rte_hash *) 0x7fff32cce740 (gdb) print *key $4 = {src_addr = 419496202, dst_addr = 453050634, src_port = 53764, dst_port = 11798, proto = 17 '\021'} (gdb) print softrss $5 = 403183624 (gdb) c After I hit c, it will do the second lookup, Breakpoint 1, datapath_handle_read (dp=0x7ffff00008c0) at /home/zhangwei1984/openNetVM-master/openNetVM/examples/flow_table/sdn.c:191 191 ret = onvm_ft_lookup(sdn_ft, fk, (char**)&flow_entry); (gdb) print *sdn_ft $7 = {hash = 0x7fff32cce740, data = 0x7fff32cb0480 "", cnt = 1024, entry_size = 56} (gdb) print *fk $8 = {src_addr = 419496202, dst_addr = 453050634, src_port = 53764, dst_port = 11798, proto = 17 '\021'} (gdb) s onvm_ft_lookup (table=0x7fff32cbe4c0, key=0x7fff32b99c00, data=0x7ffff68d2b00) at /home/zhangwei1984/openNetVM-master/openNetVM/onvm/shared/onvm_flow_table.c:151 151 softrss = onvm_softrss(key); (gdb) n 152 printf("software rss %d\n", softrss); (gdb) n software rss 403183624 154 tbl_index = rte_hash_lookup_with_hash(table->hash, (const void *)key, softrss); (gdb) print table->hash $9 = (struct rte_hash *) 0x7fff32cce740 (gdb) print *key $10 = {src_addr = 419496202, dst_addr = 453050634, src_port = 53764, dst_port = 11798, proto = 17 '\021'} (gdb) print softrss $11 = 403183624 (gdb) n Program received signal SIGSEGV, Segmentation fault. 0x000000000045fb97 in __rte_hash_lookup_bulk () (gdb) bt #0 0x000000000045fb97 in __rte_hash_lookup_bulk () #1 0x0000000000000000 in ?? ()
