[Bug,339] net/af_packet: af_packet driver is leaving stale socket after device is removed

Message ID bug-339-3@http.bugs.dpdk.org/ (mailing list archive)
State Not Applicable, archived
Delegated to: Ferruh Yigit
Headers
Series [Bug,339] net/af_packet: af_packet driver is leaving stale socket after device is removed |

Checks

Context Check Description
ci/Intel-compilation fail apply issues

Commit Message

bugzilla@dpdk.org Aug. 14, 2019, 10:38 a.m. UTC
  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.sachan@altran.com
                CC: linville@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 :-
  

Comments

bugzilla@dpdk.org Aug. 19, 2019, 8:08 a.m. UTC | #1
https://bugs.dpdk.org/show_bug.cgi?id=339

abhishek sachan (abhishek.sachan@altran.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dev@dpdk.org
  

Patch

--- 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);
        }