> For performance optimizations, we need to know the input DPDK port as after > the buffer was transmitted via our ethdev driver instead of > release it back to the memory-pool we can release it to the originated HW > pool of the input port.
Then I suppose, you can have your own mempool driver, and do whatever you like there. > > > Regards, > Liron > > -----Original Message----- > From: Stephen Hemminger <step...@networkplumber.org> > Sent: Wednesday, 6 May 2020 23:11 > To: Liron Himi <lir...@marvell.com> > Cc: dpdk-dev <dev@dpdk.org> > Subject: Re: [EXT] Re: [dpdk-dev] input port in mbuf > > On Wed, 6 May 2020 19:48:26 +0000 > Liron Himi <lir...@marvell.com> wrote: > > > Fine. Is there another location or option to save this information? > > > > Regards, > > Liron > > > > -----Original Message----- > > From: Stephen Hemminger <step...@networkplumber.org> > > Sent: Wednesday, 6 May 2020 22:43 > > To: Liron Himi <lir...@marvell.com> > > Cc: dpdk-dev <dev@dpdk.org> > > Subject: [EXT] Re: [dpdk-dev] input port in mbuf > > > > External Email > > > > ---------------------------------------------------------------------- > > On Wed, 6 May 2020 19:21:30 +0000 > > Liron Himi <lir...@marvell.com> wrote: > > > > > Hi, > > > > > > We need to save the input port in the mbuf in order to return the buffer > > > to the right hw pool. > > > For now we use the 'port' in the mbuf as it is supposed to be for this > > > exact purpose. > > > But we noticed that some applications are override it with the > > > destination port. > > > > > > What should be the right behavior? > > > is there another location that that this information can be stored and > > > read only by the ethdev drivers? > > > > > > Regards, > > > Liron > > > > > > > There is no requirement that input port is unmodified by the application. > > The memory pool is already in the mbuf, should go there.
