From mboxrd@z Thu Jan 1 00:00:00 1970 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 172.31.29.97 by awsMail9 (envelope-from , uid 0) with qmail-scanner-1.25 (clamscan: 0.60. Clear:RC:0(172.31.29.97):. Processed in 0.304983 secs); 26 Dec 2016 14:50:00 -0000 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 From: "swati deshpande" To: Cc: "'Kedar Kulkarni'" , "'Ravi Dara'" , "'Milind Athavale'" Date: Mon, 26 Dec 2016 20:20:01 +0530 Message-ID: <024601d25f87$56d6d830$04848890$@nevisnetworks.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdJfeuGma8TNDEEjQEmI+PWYtZpL6g== Content-Language: en-us X-TMASE-Version: StarCloud-1.3-8.1.1062-22786.000 X-TMASE-Result: 10--11.295900-7.000000 X-TMASE-MatchedRID: PYYU0ZXim+Eae3wu1kBE94SvKOGqLLPKKFFZAe4nyZ6wGrhQUOMpw4H1 IsNTjni4jQw/nBQrLtICfthpr1Y8rxf+TLxNffg6gZTbeFUhryFu95mt47DzNhFT6ltzclWN3xY zrKTVZ0hkxl199COY7zKyFbQ4KWrbS22k34pVV31VTfJWlqPdDGUyLrXVREJVWltirZ/iPP5MAH Vbmze1TnWhc/JFQjoco2RTRsK++SVDKVWWbGcmRrxygpRxo469GDp0A8FqdMQHiwiF9OOogYzS8 a3MSlYlHvYNMYi1Zcw0E689DfEFHf4wKFk6gUul2zNZ+bvs0+t2L/JYguM0exc+nzs86r3GcIaD pdIRhp3ZfQx3B5aMuGwxGhOxvQNg319rGX8jiaGeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPB9j2G wzTE3vbyah9aCYUCHJyENlLxgz2KcCQ3weylaQC2srxpdLr/6zRtO6G5absnc9js3Ky3uXx5M73 aRgCbIJptTkaVM6I7NJ+ZwfVcusgsKQUJfVEtZ X-TM-Deliver-Signature: 5D8F599C24998D8AE476D7CC8565D9FE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] configuring network interface up/down using kni device causes crash in i40e driver X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2016 14:50:04 -0000 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