+* rte_atomicNN_xxx: These APIs do not take memory order parameter. This does
+ not allow for writing optimized code for all the CPU architectures supported
+ in DPDK. DPDK will adopt C11 atomic operations semantics and provide wrappers
+ using C11 atomic built-ins. These wrappers must be used for patches that
+ need to be merged in 20.08 onwards. This change will not introduce any
+ performance degradation.
+
+* rte_smp_*mb: These APIs provide full barrier functionality. However, many
+ use cases do not require full barriers. To support such use cases, DPDK will
+ adopt C11 barrier semantics and provide wrappers using C11 atomic built-ins.
+ These wrappers must be used for patches that need to be merged in 20.08
+ onwards. This change will not introduce any performance degradation.
+
+* igb_uio: In the view of reducing the kernel dependency from the main tree,
+ as a first step, the Technical Board decided to move ``igb_uio``
+ kernel module to the dpdk-kmods repository in the /linux/igb_uio/ directory
+ in 20.11.
+ Minutes of Technical Board Meeting of `2019-11-06
+ <https://mails.dpdk.org/archives/dev/2019-November/151763.html>`_.
+
+* lib: will fix extending some enum/define breaking the ABI. There are multiple
+ samples in DPDK that enum/define terminated with a ``.*MAX.*`` value which is
+ used by iterators, and arrays holding these values are sized with this
+ ``.*MAX.*`` value. So extending this enum/define increases the ``.*MAX.*``
+ value which increases the size of the array and depending on how/where the
+ array is used this may break the ABI.
+ ``RTE_ETH_FLOW_MAX`` is one sample of the mentioned case, adding a new flow
+ type will break the ABI because of ``flex_mask[RTE_ETH_FLOW_MAX]`` array
+ usage in following public struct hierarchy:
+ ``rte_eth_fdir_flex_conf -> rte_fdir_conf -> rte_eth_conf (in the middle)``.
+ Need to identify this kind of usages and fix in 20.11, otherwise this blocks
+ us extending existing enum/define.
+ One solution can be using a fixed size array instead of ``.*MAX.*`` value.
+
+* ethdev: Split the ``struct eth_dev_ops`` struct to hide it as much as possible
+ will be done in 20.11.
+ Currently the ``struct eth_dev_ops`` struct is accessible by the application
+ because some inline functions, like ``rte_eth_tx_descriptor_status()``,
+ access the struct directly.
+ The struct will be separate in two, the ops used by inline functions will be
+ moved next to Rx/Tx burst functions, rest of the ``struct eth_dev_ops`` struct
+ will be moved to header file for drivers to hide it from applications.