From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Kiely Subject: Question about zero length segments in received mbuf Date: Fri, 16 Oct 2015 14:32:15 +0100 Message-ID: <5620FC5F.30307@brocade.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit To: Return-path: Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by dpdk.org (Postfix) with ESMTP id 89B448DA1 for ; Fri, 16 Oct 2015 15:32:27 +0200 (CEST) Received: from pps.filterd (m0000542.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t9GDLAXc020964 for ; Fri, 16 Oct 2015 06:32:26 -0700 Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 1xjf4hjjuy-2 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 16 Oct 2015 06:32:26 -0700 List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi, I am currently experiencing a serious issue and was hoping someone else might have encountered it. I have a KVM VM using two ixgbe interfaces A and B (configured to use PCI passthrough) and forwarding traffic from interface A via B. At about 4 million pps of 64 byte frames, the rx driver ixgbe_recv_scattered_pkts_vec() appears to be generating mbufs with 2 segments, the first of which has data_len ==0 and the second data_len==64. The real problem is that when ixgbe_xmit_pkts() on the tx side gets about 18 of these packets, it seems to mess up the transmit descriptor handling. ixgbe_xmit_cleanup() never sees the STAT_DD bit set and no descriptor get freed leading to total traffic loss. I'm still debugging the xmit side to find out what's causing the descriptor ring problem. Has anyone encountered the rx side zero-length-segment issue ? I found a reference to such an issue on the web but it was years old. I'm using DPDK 1.8.0. Any information gratefully received, Tom