From: Liron Himi <lironh@marvell.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: dpdk-dev <dev@dpdk.org>, Liron Himi <lironh@marvell.com>
Subject: Re: [dpdk-dev] [EXT] Re: input port in mbuf
Date: Sat, 16 Jan 2021 20:01:42 +0000 [thread overview]
Message-ID: <DM5PR18MB2214B49E8377DF8B5A36F274C6A61@DM5PR18MB2214.namprd18.prod.outlook.com> (raw)
In-Reply-To: <20200506132342.231ca2ba@hermes.lan>
Hi,
Sorry for rearising this issue again, please check my comments inline
Liron Himi
-----Original Message-----
From: Stephen Hemminger <stephen@networkplumber.org>
Sent: Wednesday, 6 May 2020 23:24
To: Liron Himi <lironh@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 <lironh@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?
next prev parent reply other threads:[~2021-01-16 20:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-06 19:21 [dpdk-dev] " Liron Himi
2020-05-06 19:42 ` Stephen Hemminger
2020-05-06 19:48 ` [dpdk-dev] [EXT] " Liron Himi
2020-05-06 20:10 ` Stephen Hemminger
2020-05-06 20:17 ` Liron Himi
2020-05-06 20:23 ` Stephen Hemminger
2021-01-16 20:01 ` Liron Himi [this message]
2021-01-27 16:58 ` Tom Barbette
2021-01-27 17:59 ` Liron Himi
2020-05-06 22:10 ` Ananyev, Konstantin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DM5PR18MB2214B49E8377DF8B5A36F274C6A61@DM5PR18MB2214.namprd18.prod.outlook.com \
--to=lironh@marvell.com \
--cc=dev@dpdk.org \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).