Re: [dpdk-dev] Minutes of Technical Board Meeting, 2021-Oct-27

[Jerin Jacob <jerinjacobk@gmail.com>]

On Fri, Nov 19, 2021 at 1:39 AM Honnappa Nagarahalli
<Honnappa.Nagarahalli@arm.com> wrote:
>
> <snip>
> > >
> > > > > > There was a comment to remove the TLV length. I will do that
> > > > > > next version with implementation.
> > > > > >
> > > > > > Identified the following set of work for this.
> > > > > >
> > > > > > 1) Common code at lib/dwa/
> > > > > > 2) Marvell DPU based driver at drivers/dwa/cnxk/
> > > > > > 3) Test application at app/test-dwa/
> > > > > > 4) It is possible to have an SW driver(To allow non-specialized
> > > > > > HW to use the
> > > > > > framework) for this by:
> > > > > > a) Emulate DWA HW as a separate DPDK process
> > > > > > b) Add drivers/dwa/sw/ and use memif driver so to create a
> > > > > > communication channel between emulated DWA HW process and
> > DPDK
> > > > application.
> > > > > Why use memif driver? Why not ring-pmd?
> > > >
> > > > Planning to emulation DWA accelerator functional model as a separate
> > > > DPDK process in SW case.
> > > You mean the primary and secondary processes correct?
> >
> > Primary and Primary. (DWA emulation as a separate primary process to mimic
> > the real-world scenario)
> >
> > >
> > > > Therefore memif is the ideal choice as it supports zero-copy of the
> > > > data as well.
> > > > https://doc.dpdk.org/guides/nics/memif.html
> > > Zero-copy in memif is nothing but exchanging pointers to shared data.
> > > The rings work across the primary and secondary processes and are always
> > zero-copy.
> > > We are doing some perf comparisons between memif and rings, will let you
> > know once we have the data.
> >
> > Ok.
> > I think between primary to primary memif will be required.
> Agree, memif is easier/required between primary to primary. But, using it with zero-copy would need additional code on the application part in this scenario. The memory being shared needs to be mapped in both the processes.

The existing memif driver does it internally for all memsegs [1]. Even
if it is not, it will be abstracted in profile and driver, to make the
application transparent on transport aspects.

[1]

static int
memif_regions_init(struct rte_eth_dev *dev)
{
        struct pmd_internals *pmd = dev->data->dev_private;
        int ret;

        /*
         * Zero-copy exposes dpdk memory.
         * Each memseg list will be represented by memif region.
         * Zero-copy regions indexing: memseg list idx + 1,
         * as we already have region 0 reserved for descriptors.
         */
        if (pmd->flags & ETH_MEMIF_FLAG_ZERO_COPY) {
                /* create region idx 0 containing descriptors */
                ret = memif_region_init_shm(dev, 0);
                if (ret < 0)
                        return ret;
                ret = rte_memseg_walk(memif_region_init_zc, (void
*)dev->process_private);
                if (ret < 0)
                        return ret;
        } else {
                /* create one memory region contaning rings and buffers */
                ret = memif_region_init_shm(dev, /* has buffers */ 1);
                if (ret < 0)
                        return ret;
        }

        return 0;
}

>
> >
> > >
> > > >
> > > > >
> > > > > > c) Add drivers/dwa/sw/profiles//l3fwd - To implement l3fwd
> > > > > > profile using DPDK libraries for SW driver.
> > > > > >
> > > > > > I think, Item (4) aka SW drivers as useful(We don't need to
> > > > > > implement for all profiles, I think, just for  l3fwd it make
> > > > > > sense to add, to allow to use of the framework in just SW mode).
> > > > > > Is there any opinion on adding item (4) in DPDK? I saw mixed
> > > > > > opinions earlier on this. I would like to understand, Is there
> > > > > > any objection to doing
> > > > > > item(4) in DPDK as it needs a good amount of work and  I don't
> > > > > > want to do throw it away if the community doesn't like this.
> > > > > > Any opinion?
> > > > > >
> > > > > > [1]
> > > > > > http://mails.dpdk.org/archives/dev/2021-October/226070.html
> > > > > >
> > > > > <snip>