https://bugs.dpdk.org/show_bug.cgi?id=339
Bug ID: 339
Summary: net/af_packet: af_packet driver is leaving stale
socket after device is removed
Product: DPDK
Version: 18.02
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: abhishek.sac...@altran.com
CC: linvi...@tuxdriver.com
Target Milestone: ---
I am trying to use af_packet dpdk pmd driver in "ovs with dpdk".
Looks like af_packet driver is leaving stale sockets after device is removed.
The stale sockets can be confirmed by the output of "ss -0" command.
Kindly let me know if this is known/valid issue.
Have suggested a code change in dpdk net/af_packet to fix the issue, please
suggest if this is appropriate fix so that i can submit a patch.
Below is the output of "ss -0" after addition and deletion of port in ovs :
[1] Add port in ovs using command "ovs-vsctl add-port br0 wan -- set Interface
wan type=dpdk options:dpdk-devargs=eth_af_packet0,iface=veth0"
#ss -0
Netid Recv-Q Send-Q Local Address:Port
Peer Address:Port
p_raw 0 0 *:veth0
*
[2] Delete port in ovs using command "ovs-vsctl del-port br0 wan"
#ss -0
Netid Recv-Q Send-Q Local Address:Port
Peer Address:Port
p_raw 0 0 *:veth0
*
"ss -0" output keeps showing stale entry , and the stale entries keeps piling
up with multiple add/del triggered for same port in ovs.
All the entries gets removed only when ovs process is exited.
Went through dpdk net/af_packet code and below are the findings:-
[1] Ring buffers are memory mapped when device is added using rte_dev_probe
[2] There is no corresponding munmap call when device is removed/closed
[3] The issue is fixed by calling munmap from rte_pmd_af_packet_remove()
Patch for changes done to fix the issue :-
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -972,6 +972,7 @@
{
struct rte_eth_dev *eth_dev = NULL;
struct pmd_internals *internals;
+ struct tpacket_req *req;
unsigned q;
PMD_LOG(INFO, "Closing AF_PACKET ethdev on numa socket %u",
@@ -992,7 +993,10 @@
return rte_eth_dev_release_port(eth_dev);
internals = eth_dev->data->dev_private;
+ req = &(internals->req);
for (q = 0; q < internals->nb_queues; q++) {
+ munmap(internals->rx_queue[q].map,
+ 2 * req->tp_block_size * req->tp_block_nr);
rte_free(internals->rx_queue[q].rd);
rte_free(internals->tx_queue[q].rd);
}
--
You are receiving this mail because:
You are the assignee for the bug.
