Re: [dpdk-dev] [PATCH] doc: add graphic showing layout of mbuf struct
> -Original Message- > From: dev On Behalf Of A.McLoughlin > Sent: Friday, August 23, 2019 6:40 PM > To: John McNamara ; Marko Kovacevic > ; Olivier Matz > Cc: dev@dpdk.org; harry.van.haa...@intel.com; A.McLoughlin > > Subject: [dpdk-dev] [PATCH] doc: add graphic showing layout of mbuf struct > > This patch adds a graphical overview of the rte_mbuf struct, showing where > each value is stored within the struct. > > Signed-off-by: A.McLoughlin > --- > doc/guides/prog_guide/img/mbuf_graphic.svg | 7285 > doc/guides/prog_guide/mbuf_lib.rst |9 + > 2 files changed, 7294 insertions(+) > create mode 100644 doc/guides/prog_guide/img/mbuf_graphic.svg The diagram shows uint16_t refcnt(+atomic). I think, +atomic is not need here.
Re: [dpdk-dev] [PATCH v2 2/7] ethdev: add mbuf RSS update as an offload
On Thu, 22 Aug 2019 02:17:50 +0530 wrote: > From: Pavan Nikhilesh > > Add new Rx offload flag `DEV_RX_OFFLOAD_RSS_HASH` which can be used to > enable/disable PMDs write to `rte_mbuf::hash::rss`. > PMDs notify the validity of `rte_mbuf::hash:rss` to the applcation > by enabling `PKT_RX_RSS_HASH ` flag in `rte_mbuf::ol_flags`. > > Signed-off-by: Pavan Nikhilesh > Reviewed-by: Andrew Rybchenko Is this really a good idea? Every bit of hardware that works on Windows with RSS is required to supply the hash (for software steering). So if adding an additional capability, just adds another bit of complexity, code coverage, and one more thing that won't be tested by everyone. If hardware has it why not set it? Adding a branch is more expensive than an unused assignment.
Re: [dpdk-dev] [RFC PATCH 3/3] lib/lpm: integrate RCU QSBR
On Thu, 22 Aug 2019 14:34:57 +0800 Ruifeng Wang wrote: > Currently, the tbl8 group is freed even though the readers might be > using the tbl8 group entries. The freed tbl8 group can be reallocated > quickly. This results in incorrect lookup results. > > RCU QSBR process is integrated for safe tbl8 group reclaim. > Refer to RCU documentation to understand various aspects of > integrating RCU library into other libraries. > > Signed-off-by: Ruifeng Wang > Reviewed-by: Honnappa Nagarahalli > Reviewed-by: Gavin Hu Having RCU in LPM is a good idea but difficult to find out how to do it in DPDK. Not everyone wants to use RCU, so making a required part of how LPM is used will impact users. Also, it looks like DPDK RCU lacks a good generic way to handle deferred free. Having to introduce a ring to handle is adding more complexity when a generic solution would be better (see userspace RCU library for example). Other parts of DPDK would benefit if deferred free was done better.
Re: [dpdk-dev] [PATCH 0/2] IXGBE vPMD changes for aarch64
Hi, Thanks for the patches, could you also provide the Fixes tag and cc stable? The patchset looks good to me. Thanks, Xiaolong On 08/13, Ruifeng Wang wrote: >Couple of changes to IXGBE vector PMD on aarch64 platform. >An unnecessary memory barrier was identified and removed. >Also part of processing was replaced with NEON intrinsics. >Both of the changes will help to improve performance. > >Ruifeng Wang (2): > net/ixgbe: remove barrier in vPMD for aarch64 > net/ixgbe: use neon intrinsics to count packet for aarch64 > > drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c | 32 - > 1 file changed, 16 insertions(+), 16 deletions(-) > >-- >2.17.1 >
