From: Olivier Matz <olivier.matz@6wind.com>
To: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
Cc: dev@dpdk.org, shahafs@mellanox.com, matan@mellanox.com,
rasland@mellanox.com, thomas@monjalon.net, orika@mellanox.com
Subject: Re: [dpdk-dev] [RFC v2] mlx5/net: hint PMD not to inline packet
Date: Fri, 27 Dec 2019 09:59:46 +0100 [thread overview]
Message-ID: <20191227085946.GM22738@platinum> (raw)
In-Reply-To: <1576083693-26199-1-git-send-email-viacheslavo@mellanox.com>
Hi Viacheslav,
On Wed, Dec 11, 2019 at 05:01:33PM +0000, Viacheslav Ovsiienko wrote:
> Some PMDs inline the mbuf data buffer directly to device transmit descriptor.
> This is in order to save the overhead of the PCI headers imposed when the
> device DMA reads the data by buffer pointer. For some devices it is essential
> in order to provide the full bandwidth.
>
> However, there are cases where such inlining is in-efficient. For example, when
> the data buffer resides on other device memory (like GPU or storage device).
> Attempt to inline such buffer will result in high PCI overhead for reading
> and copying the data from the remote device to the host memory.
>
> To support a mixed traffic pattern (some buffers from local host memory, some
> buffers from other devices) with high bandwidth, a hint flag is introduced in
> the mbuf.
>
> Application will hint the PMD whether or not it should try to inline the
> given mbuf data buffer. PMD should do the best effort to act upon this request.
>
> The hint flag RTE_NET_MLX5_DYNFLAG_NO_INLINE_NAME is supposed to be dynamic,
> registered by application with rte_mbuf_dynflag_register(). This flag is
> purely vendor specific and declared in PMD specific header rte_pmd_mlx5.h,
> which is intended to be used by specific application.
>
> To query the supported specific flags in runtime the private routine is
> introduced:
>
> int rte_pmd_mlx5_get_dyn_flag_names(
> uint16_t port,
> char *names[],
> uint16_t n)
>
> It returns the array of currently (over present hardware and configuration)
> supported specific flags.
>
> The "not inline hint" feature operating flow is the following one:
> - application start
> - probe the devices, ports are created
> - query the port capabilities
> - if port supporting the feature is found
> - register dynamic flag RTE_NET_MLX5_DYNFLAG_NO_INLINE_NAME
> - application starts the ports
> - on dev_start() PMD checks whether the feature flag is registered and
> enables the feature support in datapath
> - application might set this flag in ol_flags field of mbuf in the packets
> being sent and PMD will handle ones appropriately.
>
> Signed-off-by: Shahaf Shuler <shahafs@mellanox.com>
> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
>
> ---
> v1: https://patches.dpdk.org/patch/61348/
>
It looks the patch is missing.
I think a dynamic flag is the good solution for this problem: the pmd
can send a pmd-specific hint to the application, without impacting the
way it works today.
Olivier
next prev parent reply other threads:[~2019-12-27 8:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-17 7:27 [dpdk-dev] [RFC PATCH 20.02] mbuf: " Shahaf Shuler
2019-10-17 8:16 ` Jerin Jacob
2019-10-17 10:59 ` Shahaf Shuler
2019-10-17 17:18 ` Jerin Jacob
2019-10-22 6:26 ` Shahaf Shuler
2019-10-22 15:17 ` Jerin Jacob
2019-10-23 11:24 ` Shahaf Shuler
2019-10-25 11:17 ` Jerin Jacob
2019-10-17 15:14 ` Stephen Hemminger
2019-10-22 6:29 ` Shahaf Shuler
2019-12-11 17:01 ` [dpdk-dev] [RFC v2] mlx5/net: " Viacheslav Ovsiienko
2019-12-27 8:59 ` Olivier Matz [this message]
2020-01-14 7:57 ` [dpdk-dev] [PATCH] net/mlx5: update Tx datapath to support no inline hint Viacheslav Ovsiienko
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=20191227085946.GM22738@platinum \
--to=olivier.matz@6wind.com \
--cc=dev@dpdk.org \
--cc=matan@mellanox.com \
--cc=orika@mellanox.com \
--cc=rasland@mellanox.com \
--cc=shahafs@mellanox.com \
--cc=thomas@monjalon.net \
--cc=viacheslavo@mellanox.com \
/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).