Le 16/01/2021 à 21:01, Liron Himi a écrit : > Hi, > > Sorry for rearising this issue again, please check my comments inline > > Liron Himi > > -----Original Message----- > From: Stephen Hemminger > Sent: Wednesday, 6 May 2020 23:24 > To: Liron Himi > Cc: dpdk-dev > Subject: Re: [EXT] Re: [dpdk-dev] input port in mbuf > > On Wed, 6 May 2020 20:17:20 +0000 > Liron Himi wrote: > >> 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. > But you can't be sure where the mbuf came from. > It could be a receive on any vendors driver, or it could be from a private pool that is used for transmit, or anywhere. > > [L.H.] I'm only referring to PP2->PP2 flow on an Armada platform. For any other flow the transmitted buffer will be returned to its 'mb'. > > Please reconsider the real nature here; the world is not testpmd, l2fwd, l3fwd etc. > These are the kind of optimizations that break real applications and cause more trouble than the benefit for one silly benchmark. > > [L.H.] I don't want to influence application usage, this is why I asked if there is a location in the mbuf where a driver can put its own info. Like the private area for the application, but just for the input driver. > And if there is no such location right now, will it be acceptable to introduce such one? Isn't  it the purpose of RTE Mbuf dynamic fields ? You could register a field that only your driver knows about.