From mboxrd@z Thu Jan 1 00:00:00 1970 From: "swati deshpande" Subject: configuring network interface up/down using kni device causes crash in i40e driver Date: Mon, 26 Dec 2016 20:20:01 +0530 Message-ID: <024601d25f87$56d6d830$04848890$@nevisnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "'Kedar Kulkarni'" , "'Ravi Dara'" , "'Milind Athavale'" To: Return-path: Received: from rout5.hes.trendmicro.com (rout5.hes.trendmicro.com [54.219.188.3]) by dpdk.org (Postfix) with ESMTP id 1D7032C8 for ; Mon, 26 Dec 2016 15:50:04 +0100 (CET) Received: from 0.0.0.0_hes.trendmicro.com (unknown [10.64.10.13]) by rout5.hes.trendmicro.com (Postfix) with SMTP id 46CCDEFC049 for ; Mon, 26 Dec 2016 14:50:03 +0000 (UTC) Received: from mail9.mithiskyconnect.com (unknown [52.77.115.137]) by relay1.hes.trendmicro.com (Postfix) with ESMTP id ADB43142C03A for ; Mon, 26 Dec 2016 14:50:01 +0000 (UTC) Received: from mail9.mithiskyconnect.com (localhost.localdomain [127.0.0.1]) by mail9.mithiskyconnect.com (SMF) with ESMTP id C5F931851FB for ; Mon, 26 Dec 2016 20:20:00 +0530 (IST) Received: from mail9.mithi.com (localhost.localdomain [127.0.0.1]) by mail9.mithiskyconnect.com (bulkSplit) with ESMTP id BAC831851F9 for ; Mon, 26 Dec 2016 20:20:00 +0530 (IST) Received: from unknown (HELO swatipcfordcio) (swati.deshpande@nevisnetworks.com@[172.31.29.97]) (envelope-sender ) by 0 (qmail-ldap-1.03) with AES256-GCM-SHA384 encrypted SMTP for ; 26 Dec 2016 14:50:00 -0000 Content-Language: en-us List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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