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.
