[dpdk-dev] [EXT] Re: input port in mbuf

Tom Barbette barbette at kth.se
Wed Jan 27 17:58:59 CET 2021


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 <stephen at networkplumber.org>
> Sent: Wednesday, 6 May 2020 23:24
> To: Liron Himi <lironh at marvell.com>
> Cc: dpdk-dev <dev at dpdk.org>
> Subject: Re: [EXT] Re: [dpdk-dev] input port in mbuf
>
> On Wed, 6 May 2020 20:17:20 +0000
> Liron Himi <lironh at 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.



More information about the dev mailing list