[dpdk-dev] [PATCH v7 9/9] doc: dynamic rss configuration for bonding

[dpdk-dev] [PATCH v7 9/9] doc: dynamic rss configuration for bonding

[Tomasz Kulasek]

Date: Fri, 30 Oct 2015 14:56:04 +0100
Message-Id: <1446213364-11856-10-git-send-email-tomaszx.kulasek@intel.com>
X-Mailer: git-send-email 2.1.4
In-Reply-To: <1446213364-11856-1-git-send-email-tomaszx.kulasek@intel.com>
References: <1444989651-6236-1-git-send-email-tomaszx.kulasek@intel.com>
 <1446213364-11856-1-git-send-email-tomaszx.kulasek@intel.com>

Documentation update about implementation details and requirements for

Dynamic RSS Configuration for Bonding.



Signed-off-by: Tomasz Kulasek <tomaszx.kulasek@intel.com>

Acked-by: Declan Doherty <declan.doherty@intel.com>

---

 .../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

[dpdk-dev] [PATCH v7 9/9] doc: dynamic rss configuration for bonding

[Tomasz Kulasek]

Documentation update about implementation details and requirements for
Dynamic RSS Configuration for Bonding.

Signed-off-by: Tomasz Kulasek <tomaszx.kulasek@intel.com>
Acked-by: Declan Doherty <declan.doherty@intel.com>
---
 .../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