From patchwork Wed Jun 3 10:59:07 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tomasz Kulasek X-Patchwork-Id: 5101 Return-Path: X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id F2C5AB3D6; Wed, 3 Jun 2015 13:09:48 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 388B09A9E for ; Wed, 3 Jun 2015 13:09:47 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP; 03 Jun 2015 04:09:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,546,1427785200"; d="scan'208";a="740072103" Received: from unknown (HELO Sent) ([10.217.248.134]) by orsmga002.jf.intel.com with SMTP; 03 Jun 2015 04:09:45 -0700 Received: by Sent (sSMTP sendmail emulation); Wed, 03 Jun 2015 13:08:40 +0200 From: Tomasz Kulasek To: dev@dpdk.org Date: Wed, 3 Jun 2015 12:59:07 +0200 Message-Id: <1433329147-2840-9-git-send-email-tomaszx.kulasek@intel.com> X-Mailer: git-send-email 2.1.4 In-Reply-To: <1433329147-2840-1-git-send-email-tomaszx.kulasek@intel.com> References: <1433329147-2840-1-git-send-email-tomaszx.kulasek@intel.com> Subject: [dpdk-dev] [PATCH 8/8] doc: dynamic rss configuration for bonding X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list 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" Documentation update about implementation details and requirements for Dynamic RSS Configuration for Bonding. Signed-off-by: Tomasz Kulasek --- .../prog_guide/link_bonding_poll_mode_drv_lib.rst | 32 ++++++++++++++++++-- 1 file changed, 30 insertions(+), 2 deletions(-) diff --git a/doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst b/doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst index 03baf90..7f06cbe 100644 --- a/doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst +++ b/doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst @@ -1,5 +1,5 @@ .. BSD LICENSE - Copyright(c) 2010-2014 Intel Corporation. All rights reserved. + Copyright(c) 2010-2015 Intel Corporation. All rights reserved. All rights reserved. Redistribution and use in source and binary forms, with or without @@ -173,7 +173,27 @@ After a slave device is added to a bonded device slave is stopped using ``rte_eth_dev_stop`` and then reconfigured using ``rte_eth_dev_configure`` the RX and TX queues are also reconfigured using ``rte_eth_tx_queue_setup`` / ``rte_eth_rx_queue_setup`` with the parameters use to configure the bonding -device. +device. If RSS is enabled for bonding device, this mode is also enabled on new +slave and configured as well. + +Setting up multi-queue mode for bonding device to RSS, makes it fully +RSS-capable, so all slaves are synchronized with its configuration. This mode is +intended to provide RSS configuration on slaves transparent for client +application implementation. + +Bonding device stores its own version of RSS settings i.e. RETA, RSS hash +function and RSS key, used to set up its slaves. That let to define the meaning +of RSS configuration of bonding device as desired configuration of whole bonding +(as one unit), without pointing any of slave inside. It is required to ensure +consistency and made it more errorproof. + +RSS hash function set for bonding device, is a maximal set of RSS hash functions +supported by all bonded slaves. RETA size is a GCD of all its RETA's sizes, so +it can be easily used as a pattern providing expected behavior, even if slave +RETAs' sizes are different. RSS key is always 40 bytes long. + +All settings are managed through the bonding port API and always are propagated +in one direction (from bonding to slaves). Link Status Change Interrupts / Polling ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -207,6 +227,14 @@ these parameters. A bonding device must have a minimum of one slave before the bonding device itself can be started. +To use a bonding device dynamic RSS configuration feature effectively, it is +also required, that all slaves should be RSS-capable and support, at least one +common hash function available for each of them. + +To prevent inconsistency on how slaves process packets, once a device is added +to a bonding device, RSS configuration should be managed through the bonding +device API, and not directly on the slave. + Like all other PMD, all functions exported by a PMD are lock-free functions that are assumed not to be invoked in parallel on different logical cores to work on the same target object.