-----Original Message----- From: Tom Barbette <barbe...@kth.se> Sent: Wednesday, 27 January 2021 18:59 To: Liron Himi <lir...@marvell.com>; Stephen Hemminger <step...@networkplumber.org> Cc: dpdk-dev <dev@dpdk.org> Subject: Re: [dpdk-dev] [EXT] Re: input port in mbuf
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 <step...@networkplumber.org> > Sent: Wednesday, 6 May 2020 23:24 > 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 20:17:20 +0000 > Liron Himi <lir...@marvell.com> 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. [L.H.] Thanks, I will explore this option
