From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 3FD3E1B6FE for ; Fri, 10 Nov 2017 16:18:24 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga104.jf.intel.com with ESMTP; 10 Nov 2017 07:18:23 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.44,374,1505804400"; d="scan'208";a="6206643" Received: from dwdohert-mobl.ger.corp.intel.com (HELO [163.33.228.189]) ([163.33.228.189]) by orsmga002.jf.intel.com with ESMTP; 10 Nov 2017 07:18:22 -0800 To: Kyle Larose , "dev@dpdk.org" References: From: "Doherty, Declan" Message-ID: <0a82c7db-894c-1cc4-53da-4afb2c54e3ba@intel.com> Date: Fri, 10 Nov 2017 15:18:22 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] rte_eth_bond 8023ad dedicated queues with i40e with vectorized rx does not work 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: Fri, 10 Nov 2017 15:18:25 -0000 On 08/11/2017 7:21 PM, Kyle Larose wrote: > Hello, > > I've been doing some testing using the 8023ad link bonding driver on a system with 4 10G i40e interfaces in the link bond. It's working fine, except that when any of the links are overloaded, it starts dropping the LACPDUs, which is rather unfortunate for many reasons. > > While thinking about that problem, I noticed that the driver provides the ability to allocate dedicated queues for rx and tx of LACPDUs. This is great! Solves my problem (sort of - I'll send another email about that later)... Or so I thought. After enabling the dedicated queues, I noticed a few things: > 1. The link bond never started distributing > 2. The slave interfaces started dropping frames on their dedicated control queues after some time > 3. The connected interfaces reported both sending and receiving LACP PDUs. > > After digging in to this, I found out that the call to rte_eth_rx_burst was returning 0 packets, despite their being many in the queue. It turns out that the i40e was using one of the vectorized rx_burst functions, which require that the user poll for more than 1 packet at a time. bond_mode_8023ad_periodic_cb was polling for exactly one. > > I changed the code to read up to 16 at a time, and everything started working. I'm not sure this is the right fix, though, since the normal behaviour of processing one packet at a time maintains some hold offs/etc that may be nice, and I don't want to discard any packets past the first one. > > Does anyone have some thoughts/comments on this? I can submit a patch with my current workaround, if desired. > > Thanks, > > Kyle > Hey Kyle, I think this fix is fine, as is possible that there would be more than one packet on the queue, with both control packets and marker packets possible. Please send a patch so we can review and try out. Thanks Declan