On Fri, Nov 19, 2021 at 1:39 AM Honnappa Nagarahalli
<honnappa.nagaraha...@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>
