[PATCH v3 1/1] app/testpmd: add GPU memory option for mbuf pools

[Jerin Jacob]

On Wed, Nov 17, 2021 at 6:09 PM Elena Agostini <eagostini at nvidia.com> wrote:
>
> > > >>
>
> > > >>>>
>
> > > >>
>
> > > >>>>> On Wed, 17 Nov 2021 03:04:59 +0000
>
> > > >>
>
> > > >>>>
>
> > > >>>>>> This patch introduces GPU memory in testpmd through the gpudev library.
>
> > > >>
>
> > > >>>>
>
> > > >>
>
> > > >>>>>> Testpmd can be used for network benchmarks when using GPU memory
>
> > > >>
>
> > > >>>>
>
> > > >>
>
> > > >>>>>> instead of regular CPU memory to send and receive packets.
>
> > > >>
>
> > > >>>>
>
> > > >>
>
> > > >>>>>> This option is currently limited to iofwd engine to ensure
>
> > > >>
>
> > > >>>>
>
> > > >>
>
> > > >>>>>> no workload is applied on packets not accessible from the CPU.
>
> > > >>
>
> > > >>>>
>
> > > >>
>
> > > >>>>>>
>
> > > >>
>
> > > >>>>
>
> > > >>
>
> > > >>>>>> The options chose is --mbuf-size so buffer split feature across
>
> > > >>
>
> > > >>>>
>
> > > >>
>
> > > >>>>>> different mempools can be enabled.
>
> > > >>
>
> > > >>>>
>
> > > >>
>
> > > >>>>>>
>
> > > >>
>
> > > >>>>
>
> > > >>
>
> > > >>>>>> Signed-off-by: Elena Agostini <eagostini at nvidia.com>
>
> > > >>
>
> > > >>>>
>
> > > >>
>
> > > >>>>>
>
> > > >>
>
> > > >>>>
>
> > > >>
>
> > > >>>>> Won't this create a hard dependency of test-pmd on gpudev?
>
> > > >>
>
> > > >>>>
>
> > > >>
>
> > > >>>>> I thought gpudev was supposed to be optional
>
> > > >>
>
> > > >>>>
>
> > > >>
>
> > > >>>>
>
> > > >>
>
> > > >>>>
>
> > > >>
>
> > > >>>> Sure, let me submit another patch to make it optional
>
> > > >>
>
> > > >>>
>
> > > >>
>
> > > >>> Why to add yet another compile time macro everywhere in testpmd and
>
> > > >>
>
> > > >>> make hard to maintain?
>
> > > >>
>
> > > >>> Adding iofwd kind of code is very simple to add test/test-gpudev and
>
> > > >>
>
> > > >>> all GPU specific options
>
> > > >>
>
> > > >>> can be added in test-gpudev. It also helps to review the patches as
>
> > > >>
>
> > > >>> test cases focus on
>
> > > >>
>
> > > >>> each device class.
>
> > > >>
>
> > > >>
>
> > > >>
>
> > > >> Test-gpudev is standalone unit test to ensure gpudev functions work correctly.
>
> > > >>
>
> > > >> In testpmd instead, there is a connection between gpudev and the network.
>
> > > >
>
> > > > I understand that. We had the same case with eventdev, where it needs to
>
> > > > work with network. Testpmd is already complicated, IMO, we should
>
> > > > focus only ethdev
>
> > > > test cases on testpmd, test-gpudev can use ethdev API to enable
>
> > > > networking requirements for gpudev.
>
> > > >
>
> > >
>
> > > +1
>
> >
>
> > +1
>
>
>
> Testpmd already manages different type of memories for mempools.
>
> gpudev is just another type of memory, there is nothing more than that.

Let take this example:
1) New code changes

 app/test-pmd/cmdline.c    |  32 +++++++-
 app/test-pmd/config.c     |   4 +-
 app/test-pmd/icmpecho.c   |   2 +-
 app/test-pmd/meson.build  |   2 +-
 app/test-pmd/parameters.c |  15 +++-
 app/test-pmd/testpmd.c    | 167 +++++++++++++++++++++++++++++++++++---
 app/test-pmd/testpmd.h    |  16 +++-
 7 files changed, 217 insertions(+), 21 deletions(-)

2) Good amount of code need to go through condition compilation as
gpudev is optional that make
testpmd further ugly.

3) It introduces new memtype, now

+enum mbuf_mem_type {
+ MBUF_MEM_CPU,
+ MBUF_MEM_GPU
+};

The question largely, why testpmd need to pollute for this, testpmd,
we are using for testing ethdev device class.
All we are saying is to enable this use case in test-gpudev so that it
focuses on GPU specific, Whoever is not
interested in specific libraries do not even need to review the testpmd patches.