Bug 338
Summary: | IP Reassembly with more 4 packets Segfault | ||
---|---|---|---|
Product: | DPDK | Reporter: | Abhijeet (abhijeet080808) |
Component: | core | Assignee: | Abhijeet (abhijeet080808) |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | ajit.khaparde, konstantin.v.ananyev |
Priority: | Normal | ||
Version: | 17.11 | ||
Target Milestone: | --- | ||
Hardware: | x86 | ||
OS: | Linux |
Description
Abhijeet
2019-08-13 05:05:17 CEST
> I have looked at previous mails on this mailing list and also elsewhere on > Google > and could not find any information related to this. I meant the users@dpdk.org mailing list. (gdb) p *key $1 = {src_dst = {8653288496738183178, 140737306069544, 0, 140737306069312}, id = 22534, key_len = 1} (gdb) p *tbl $4 = {max_cycles = 140735532901248, entry_mask = 2339506112, max_entries = 32767, use_entries = 2339501375, bucket_entries = 32767, nb_entries = 2339494272, nb_buckets = 32767, last = 0x7fff8b71bdc0, lru = {tqh_first = 0x7fff7bacb700, tqh_last = 0x7fff7aed8f00}, stat = {find_num = 0, add_num = 0, del_num = 0, reuse_num = 0, fail_total = 0, fail_nospace = 0}, pkt = 0x7fff7a32cf00} I had been making a mistake. My code was of format - if (rte_ipv4_frag_pkt_is_fragmented(ipv4_header)) { rte_mbuf* assembled_msg = rte_ipv4_frag_reassemble_packet(); if (assembled_msg != nullptr) { rte_ip_frag_free_death_row(); } } The rte_ip_frag_free_death_row was NOT getting called when reassembly was failing, as it was in my case of > 4 IP fragments. The fix is to call rte_ip_frag_free_death_row irrespective of reassembly status. Apparently, this is the resultant mode of failure in this scenario. Please confirm and close this bug if nothing has to be done. If you need to handle more then 4 fragments per packet, you'll need to increase CONFIG_RTE_LIBRTE_IP_FRAG_MAX_FRAG value in your config file and rebuild dpdk. Let say change it to 8 or so. Abhijeet, Can you try Konstantin's suggestion and update here? Thanks 4 fragments are good for my requirement. My issue was that greater than CONFIG_RTE_LIBRTE_IP_FRAG_MAX_FRAG fragments should be handled gracefully by dropping the fragments instead of seg faulting. As reported in comment 3, this issue was caused due to inappropriate use of the API. Once I changed the code flow from - if (rte_ipv4_frag_pkt_is_fragmented(ipv4_header)) { rte_mbuf* assembled_msg = rte_ipv4_frag_reassemble_packet(); if (assembled_msg != nullptr) { rte_ip_frag_free_death_row(); } } to - if (rte_ipv4_frag_pkt_is_fragmented(ipv4_header)) { rte_mbuf* assembled_msg = rte_ipv4_frag_reassemble_packet(); if (assembled_msg != nullptr) { // do something } rte_ip_frag_free_death_row(); } DPDK handles greater than CONFIG_RTE_LIBRTE_IP_FRAG_MAX_FRAG fragments correctly by dropping them gracefully. Are we ok to close this then? This may be closed, provided the seg fault mode of failure on using the API in the incorrect way is acceptable. |