From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 0613E2C48 for ; Wed, 5 Jul 2017 13:35:42 +0200 (CEST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jul 2017 04:35:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,311,1496127600"; d="scan'208";a="104635878" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.91]) ([10.237.220.91]) by orsmga004.jf.intel.com with ESMTP; 05 Jul 2017 04:35:40 -0700 To: Declan Doherty , dev@dpdk.org References: <20170629162022.9984-1-tomaszx.kulasek@intel.com> <20170704164627.324-1-declan.doherty@intel.com> From: Ferruh Yigit Message-ID: Date: Wed, 5 Jul 2017 12:35:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170704164627.324-1-declan.doherty@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v3 0/4] LACP control packet filtering acceleration 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: Wed, 05 Jul 2017 11:35:43 -0000 On 7/4/2017 5:46 PM, Declan Doherty wrote: > 1. Overview > > Packet processing in the current path for bonding in mode 4, requires > parse all packets in the fast path, to classify and process LACP > packets. > > The idea of performance improvement is to use hardware offloads to > improve packet classification. > > 2. Scope of work > > a) Optimization of software LACP packet classification by using > packet_type metadata to eliminate the requirement of parsing each > packet in the received burst. > > b) Implementation of classification mechanism using flow director to > redirect LACP packets to the dedicated queue (not visible by > application). > > - Filter pattern choosing (not all filters are supported by all > devices), > - Changing processing path to speed up non-LACP packets > processing, > - Handle LACP packets from dedicated Rx queue and send to the > dedicated Tx queue, > > c) Creation of fallback mechanism allowing to select the most > preferable method of processing: > > - Flow director, > - Packet type metadata, > - Software parsing, > > 3. Implementation > > 3.1. Packet type > > The packet_type approach would result in a performance improvement > as packets data would no longer be required to be read, but with this > approach the bonded driver would still need to look at the mbuf of > each packet thereby having an impact on the achievable Rx > performance. > > There's not packet_type value describing LACP packets directly. > However, it can be used to limit number of packets required to be > parsed, e.g. if packet_type indicates >L2 packets. > > It should improve performance while well-known non-LACP packets can > be skipped without the need to look up into its data. > > 3.2. Flow director > > Using rte_flow API and pattern on ethernet type of packet (0x8809), > we can configure flow director to redirect slow packets to separated > queue. > > An independent Rx queues for LACP would remove the requirement to > filter all ingress traffic in sw which should result in a performance > increase. Other queues stay untouched and processing of packets on > the fast path will be reduced to simple packet collecting from > slaves. > > Separated Tx queue for LACP daemon allows to send LACP responses > immediately, without interfering into Tx fast path. > > RECEIVE > > .---------------. > | Slave 0 | > | .------. | > | Fd | Rxq | | > Rx ======o==>| |==============. > | | +======+ | | .---------------. > | `-->| LACP |--------. | | Bonding | > | `------' | | | | .------. | > `---------------' | | | | | | > | >============>| |=======> Rx > .---------------. | | | +======+ | > | Slave 1 | | | | | XXXX | | > | .------. | | | | `------' | > | Fd | Rxq | | | | `---------------' > Rx ======o==>| |==============' .-----------. > | | +======+ | | / \ > | `-->| LACP |--------+----------->+ LACP DAEMON | > | `------' | Tx <---\ / > `---------------' `-----------' > > All slow packets received by slaves in bonding are redirected to the > separated queue using flow director. Other packets are collected from > slaves and exposed to the application with Rx burst on bonded device. > > TRANSMIT > > .---------------. > | Slave 0 | > | .------. | > | | | | > Tx <=====+===| |<=============. > | | |------| | | .---------------. > | `---| LACP |<-------. | | Bonding | > | `------' | | | | .------. | > `---------------' | | | | | | > | +<============| |<====== Tx > .---------------. | | | +======+ | > | Slave 1 | | | | | XXXX | | > | .------. | | | | `------' | > | | | | | | `---------------' > Tx <=====+===| |<=============' Rx .-----------. > | | |------| | | `-->/ \ > | `---| LACP |<-------+------------+ LACP DAEMON | > | `------' | \ / > `---------------' `-----------' > > On transmit, packets are propagated on the slaves. While we have > separated Tx queue for LACP responses, it can be sent regardless of > the fast path. > > LACP DAEMON > > In this mode whole slow packets are handled in LACP DAEMON. > > V3: > - Split hw filtering patch into 3 patches: > - fix for calculating maximum number of tx/rx queues of bonding device > - enable use of ptype hint for filtering of control plane packets in > default enablement > - enablement of dedicated queues for LACP control packet filtering. > > Declan Doherty (1): > net/bond: calculate number of bonding tx/rx queues > > Tomasz Kulasek (3): > net/bond: use ptype flags for LACP rx filtering > net/bond: dedicated hw queues for LACP control traffic > app/test-pmd: add cmd for dedicated LACP rx/tx queues Series applied to dpdk-next-net/master, thanks. (minor updates, mentioned in mail thread, done while applying.)