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.
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.
