[dpdk-dev] configuring network interface up/down using kni device causes crash in i40e driver

[swati deshpande]

Hi,

   We have implemented a packet processing application using Intel DPDK
2.1.0. 
   The system uses linux kernel 4.4.2 and has a mix of 1Gbps ( Intel i350
NIC ) and 10Gbps( Intel XL710 NIC) interfaces.
   The system has 2 NUMA nodes , with each NUMA node running 5 packet
processing threads.
   NUMA node 1 has a control thread. Kni device is created for each physical
interface in the system.
   Each packet processing thread does TX/RX on a fixed set of interfaces
using tx/rx queue designated for the core.
   The control thread polls for interface requests from kernel using
rte_kni_handle_request() on all interfaces of the system.
   If admin state is changed on kni device from Linux, while traffic is
flowing through the 10G system,
   application crashes with segmentation fault in i40e driver in function
rx_recv_pkts() or tx_xmit_pkts() function.
  There are no locks implemented in packet processing threads as no two
threads share the RX or TX queue.

   The callback handler for config_network_if  on kni device is implemented
as below, using example/kni  from DPDK as reference.
 
 static int
cpkt_pfe_kni_config_network_interface(uint8_t port_id, uint8_t if_up)
{
   
    if (port_id >= rte_eth_dev_count() || port_id >= RTE_MAX_ETHPORTS) {
    return -EINVAL;
  }

  if (if_up != 0) { /* Configure network interface up */
     ret = rte_eth_dev_start(port_id);
  } else { /* Configure network interface down */
    /* rte_eth_dev_stop() first disables interrupts
     * Hence we are not going to get link down interrupt
     * So set link state to "Down" explicitely on kni interface
     */
    ret = rte_kni_update_link_state(ifEntry->kni, 0);
     rte_eth_dev_stop(port_id);
  }
}
   
As PMD is lockless, while device stop is being executed on control thread,
packet processing threads are seen doing  rx/tx in the crashdump core.
What is the optimal way to handle network interface up/down without
introducing locks in packet processing path.
Could you please advise.

Regards,
Swati