From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 186848D91 for ; Wed, 30 Sep 2015 16:19:55 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP; 30 Sep 2015 07:19:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,612,1437462000"; d="scan'208";a="780954239" Received: from unknown (HELO Sent) ([10.217.248.94]) by orsmga001.jf.intel.com with SMTP; 30 Sep 2015 07:19:38 -0700 Received: by Sent (sSMTP sendmail emulation); Wed, 30 Sep 2015 16:18:13 +0200 From: Tomasz Kulasek To: dev@dpdk.org Date: Wed, 30 Sep 2015 16:05:05 +0200 Message-Id: <1443621905-7872-10-git-send-email-tomaszx.kulasek@intel.com> X-Mailer: git-send-email 2.1.4 In-Reply-To: <1443621905-7872-1-git-send-email-tomaszx.kulasek@intel.com> References: <1436981189-3320-1-git-send-email-tomaszx.kulasek@intel.com> <1443621905-7872-1-git-send-email-tomaszx.kulasek@intel.com> Subject: [dpdk-dev] [PATCH v5 9/9] 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: , X-List-Received-Date: Wed, 30 Sep 2015 14:19:56 -0000 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 | 34 ++++++++++++++++++-- 1 file changed, 32 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..46f0296 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,28 @@ 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. If RSS Key is not set for bonded device, it's not +changed on the slaves and default key for device is used. + +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 +228,15 @@ 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. Changing RSS key is only +possible, when all slave devices support the same key size. + +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. -- 1.7.9.5