+``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. If RSS is enabled for bonding device, this mode is also enabled on new
+slave and configured as well.
+Any flow which was configured to the bond device also is configured to the added
+slave.
+
+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 error-proof.
+
+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.
+
+As RSS configurations, there is flow consistency in the bonded slaves for the
+next rte flow operations:
+
+Validate:
+ - Validate flow for each slave, failure at least for one slave causes to
+ bond validation failure.
+
+Create:
+ - Create the flow in all slaves.
+ - Save all the slaves created flows objects in bonding internal flow
+ structure.
+ - Failure in flow creation for existed slave rejects the flow.
+ - Failure in flow creation for new slaves in slave adding time rejects
+ the slave.
+
+Destroy:
+ - Destroy the flow in all slaves and release the bond internal flow
+ memory.
+
+Flush:
+ - Destroy all the bonding PMD flows in all the slaves.
+
+.. note::
+
+ Don't call slaves flush directly, It destroys all the slave flows which
+ may include external flows or the bond internal LACP flow.
+
+Query:
+ - Summarize flow counters from all the slaves, relevant only for
+ ``RTE_FLOW_ACTION_TYPE_COUNT``.
+
+Isolate:
+ - Call to flow isolate for all slaves.
+ - Failure in flow isolation for existed slave rejects the isolate mode.
+ - Failure in flow isolation for new slaves in slave adding time rejects
+ the slave.
+
+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
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Link bonding devices support the registration of a link status change callback,
+using the ``rte_eth_dev_callback_register`` API, this will be called when the
+status of the bonding device changes. For example in the case of a bonding
+device which has 3 slaves, the link status will change to up when one slave
+becomes active or change to down when all slaves become inactive. There is no
+callback notification when a single slave changes state and the previous
+conditions are not met. If a user wishes to monitor individual slaves then they
+must register callbacks with that slave directly.
+
+The link bonding library also supports devices which do not implement link
+status change interrupts, this is achieved by polling the devices link status at
+a defined period which is set using the ``rte_eth_bond_link_monitoring_set``
+API, the default polling interval is 10ms. When a device is added as a slave to
+a bonding device it is determined using the ``RTE_PCI_DRV_INTR_LSC`` flag
+whether the device supports interrupts or whether the link status should be
+monitored by polling it.