From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 081A0A00E6 for ; Tue, 6 Aug 2019 14:21:28 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8C63C1B956; Tue, 6 Aug 2019 14:21:28 +0200 (CEST) Received: from mail.noida.interrasystems.com (mail.noida.interrasystems.com [14.141.65.140]) by dpdk.org (Postfix) with ESMTP id 868A91B955 for ; Tue, 6 Aug 2019 14:21:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.noida.interrasystems.com (Postfix) with ESMTP id 987B61F808A5; Tue, 6 Aug 2019 17:51:25 +0530 (IST) Received: from mail.noida.interrasystems.com ([127.0.0.1]) by localhost (mail.noida.interrasystems.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 91ZL_G9hLXz3; Tue, 6 Aug 2019 17:51:25 +0530 (IST) Received: from localhost (localhost [127.0.0.1]) by mail.noida.interrasystems.com (Postfix) with ESMTP id 178B11F842CA; Tue, 6 Aug 2019 17:51:25 +0530 (IST) X-Virus-Scanned: amavisd-new at noida.interrasystems.com Received: from mail.noida.interrasystems.com ([127.0.0.1]) by localhost (mail.noida.interrasystems.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZTtsuoL7eqGl; Tue, 6 Aug 2019 17:51:24 +0530 (IST) Received: from [10.218.41.112] (unknown [10.218.41.112]) by mail.noida.interrasystems.com (Postfix) with ESMTPSA id 05CD61F808A5; Tue, 6 Aug 2019 17:51:21 +0530 (IST) To: users@dpdk.org From: Vikash Kumar Organization: Interra Systems, Inc. Message-ID: <77873202-f735-bbfd-eaa6-57b90635dd3f@noida.interrasystems.com> Date: Tue, 6 Aug 2019 17:51:39 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-users] [dpdk-dev] KNI Module (multiple) to handle IGMP requests X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: vikash@interrasystems.com List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Sender: "users" Hello Everyone, Currently I am working on a project in which I need to capture the ipv4 multicast data from a managed (igmp enabled) switch. In order achieve this, I am currently using below configuration: dpdk-18.05.1. *Hardware Description:* Operating System: CentOS Linux 7 (Core) CPE OS Name: cpe:/o:centos:centos:7 Kernel: Linux 3.10.0-957.12.1.el7.x86_64 Architecture: x86-64 NIC: Ethernet 10G 2P X520 Adapter 154d (ixgbe) IG Huge Page available. Changes made in grub: isolcpus=0-1 default_hugepagesz=1G hugepagesz=1G transparent_hugepage=never" KNI Module successfully loaded as : sudo /sbin/insmod $RTE_SDK/$RTE_TARGET/kmod/rte_kni.ko kthread_mode=multiple Successfully created 16 hugepages. Successfully created hugepage filesystem. (using 'sudo mount -t hugetlbfs nodev /mnt/huge') Static IPs given to both ports of NIC. Successfully binded both the ports with igb_uio driver. Referring to KNI sample application, allocated 1 KNI module for each port. Used same MAC address, IP address, ifname same as the original NIC. Able to join multicast feeds using these kni interfaces ( setsockoptIP_ADD_SOURCE_MEMBERSHIP ) Using 1 lcore for each port. lcore 0 to capture the data over port 0 and lcore 1 to capture the data over port 1. Each of these 2 eal thread running on lcore does the below operations: rte_eth_rx_burst() -> keep copy of required multicast data and free the mbuff if copied. Else all other packets passed to kni tx (including igmp packets) rte_kni_tx_burst() rte_kni_handle_request() rte_kni_rx_burst() rte_eth_tx_burst() *_Problem Statement:_* Everything works fine with port 0. But for Port 1, I observe that there is no output from rte_kni_rx_burst, which in turn leads to multicast drop by switch. I am relying on KNI TCP/IP stack to handle the igmp - Membership Query to send the igmp - Membership Report, port-1 never send the report and hence switch drops the multicast data within few minutes. I have seen this behaviour on 2-3 machines of almost similar configuration. However, strangly on one another similar machine, the behaviour was totally opposite. There Port1 was working fine and port0 was dropping the multicast. *Please advice, what I am missing here and what can I do to debug this issue further.* ** Thanks & Regards, Vix