From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by dpdk.org (Postfix) with ESMTP id 73F5B2B82 for ; Thu, 23 Nov 2017 23:56:25 +0100 (CET) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 23 Nov 2017 17:56:24 -0500 Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Thu, 23 Nov 2017 17:56:24 -0500 From: Kyle Larose To: "dev@dpdk.org" CC: Declan Doherty Thread-Topic: rte_eth_bond: Packets are received by lag despite interface not collecting Thread-Index: AdNkkTIn/+A/0eDqQBK/3jOa8dmJOg== Date: Thu, 23 Nov 2017 22:56:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.51] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dpdk-dev] rte_eth_bond: Packets are received by lag despite interface not collecting 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: Thu, 23 Nov 2017 22:56:25 -0000 Hello, I've run into some unexpected behaviour in the rte_eth_bond pmd using 8023a= d mode with dedicated queues. bond_ethdev_rx_burst_8023ad_fast_queue iterat= es over all active slaves, and receives from each. This incorrectly ignores= whether or not the interface is collecting. If it is not collecting, the p= ackets should be discarded. Setup: - 4x10G X710 links in a 8023ad lag. 3 are connected to a switch, another to= a traffic generator. - The 3 links form the lag fine. The 4th is taken out of the distribution l= ogic, since the generator is not participating in LACP Problem: - If I send packets to a link that is not in the collecting state, the appl= ication receives those packets from the lag. It should not Analysis: - Interfaces which are up but not collecting are considered active from th= e 8023ad lag's perspective - bond_ethdev_rx_burst_8023ad_fast_queue receives traffic from all active = lags - Thus, regardless of the lacp state of the interface, traffic is received Solution: - I think that bond_ethdev_rx_burst_8023ad_fast_queue went a little too fa= r in its performance optimizations. It should still check the state of the = slave prior to accepting the packets. My suggestion: 1) If the slave is collecting, receive as normal.=20 2) Otherwise, receive the packets into the rx buffer, then free them, and = count them as being discarded due to the slave not collecting (this could b= e useful for diagnostics). 3) We receive to drain the rx queue, and so we can count. If we didn't we = could get a burst of stale packets when the link starts collecting again. 3) To try to prevent links in this state from consuming too much CPU resou= rces, we could receive only portion of the burst size at a time. Presumably it shouldn't be getting *too* much traffic, but if it is, it= 'd probably be better to overflow the rxq and drop. Thoughts? Thanks, Kyle