> -----Original Message----- > From: David Marchand <david.march...@redhat.com> > Sent: Sunday, November 1, 2020 3:11 PM > To: McDaniel, Timothy <timothy.mcdan...@intel.com> > Cc: dev <dev@dpdk.org>; Carrillo, Erik G <erik.g.carri...@intel.com>; Eads, > Gage <gage.e...@intel.com>; Van Haaren, Harry > <harry.van.haa...@intel.com>; Jerin Jacob Kollanukkaran > <jer...@marvell.com>; Thomas Monjalon <tho...@monjalon.net> > Subject: Re: [dpdk-dev] [PATCH v15 00/23] Add DLB PMD > > On Sun, Nov 1, 2020 at 8:25 PM Timothy McDaniel > <timothy.mcdan...@intel.com> wrote: > > > > The following patch series adds support for a new eventdev PMD. The DLB > > PMD adds support for the Intel Dynamic Load Balancer (DLB) hardware. > > The DLB is a PCIe device that provides load-balanced, prioritized > > scheduling of core-to-core communication. The device consists of > > queues and arbiters that connect producer and consumer cores, and > > implements load-balanced queueing features including: > > - Lock-free multi-producer/multi-consumer operation. > > - Multiple priority levels for varying traffic types. > > - 'Direct' traffic (i.e. multi-producer/single-consumer) > > - Simple unordered load-balanced distribution. > > - Atomic lock-free load balancing across multiple consumers. > > - Queue element reordering feature allowing ordered load-balanced > > distribution. > > > > The DLB hardware supports both load balanced and directed ports and > > queues. Unlike other eventdev devices already in the repo, not all > > DLB ports and queues are equally capable. In particular, directed > > ports are limited to a single link, and must be connected to a directed > > queue. > > Additionally, even though LDB ports may link multiple queues, the > > number of queues that may be linked is limited by hardware. Another > > difference is that DLB does not have a straightforward way of carrying > > the flow_id in the queue elements (QE) that the hardware operates on. > > > > While reviewing the code, please be aware that this PMD has full > > control over the DLB hardware. Intel will be extending the DLB PMD > > in the future (not as part of this first series) with a mode that we > > refer to as the bifurcated PMD. The bifurcated PMD communicates with a > > kernel driver to configure the device, ports, and queues, and memory > > maps device MMIO so datapath operations occur purely in user-space. > > > > The framework to support both the PF PMD and bifurcated PMD exists in > > this patchset, and is why the iface.[ch] layer is present. > > > > Major changes in V15 > > ==================== > > Address comments from David Marchand: > > - this patch-set is based on Nov 1, 2020 dpdk-next-eventdev > > - fix docs build (doxy-api.conf.in and doxy-api-index.md) > > - restore blank line in MAINTAINERS file > > - move dlb announcement in release_20_11.rst after ethdev > > - use headers = files() for exported meson public headers > > - fix a typo in 'add documentation ..." commit message > > - use eal version of cldemote > > - convert a couple of printfs to LOG messages > > There are still printf in drivers/event/dlb/pf/dlb_main.c from a grep > I did on v15. > Why were they kept? >
Sorry. This was an oversight on my part. I thought you had identified all of the files with printf. I should have searched all of the files, and fixed any cases that were not identified in the CR. I will fix these in the next patch-set. > + I did not look too much at the PCI code in this file, but I suspect > we could factor some of it with librte_pci. > Can we look at possibly doing that post rc2 merge? > > > - fix missing "~" in dlb documentation > > - delay introduction of _delayed token pop functions to > > token pop commit (fixes 8 or so unused function errors) > > - all patches build incrementally (gcc), and checkpatches reports > > success > > There is a valid warning on patch 6: > http://mails.dpdk.org/archives/test-report/2020-November/164347.html > > WARNING:REPEATED_WORD: Possible repeated word: 'of' > #1493: FILE: drivers/event/dlb/pf/base/dlb_osdep_bitmap.h:364: > + * Returns the bitmap's longest contiguous range of of set bits upon success, > I will address with the next patch-set. Odd that I did not see the error/warning when I ran devtools/checkpatches.sh > > > - I am not able to run clang locally. If clang errors are still > > present I will ask IT to install clang on a build server tomorrow. > > This time, compilation passed for each patch on my build system (using > ./devtools/test-meson-builds.sh, x86, arm, ppc + doc generation). Excellent news. Thanks for the update. > > > -- > David Marchand
