From: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Noa Osherovich <noaos-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Subject: Re: [PATCH rdma-next 1/2] IB/core: Add scatter end padding flags for WQ and QP
Date: Wed, 25 Oct 2017 13:58:59 -0400 [thread overview]
Message-ID: <1508954339.3325.45.camel@redhat.com> (raw)
In-Reply-To: <20171017151857.11934-2-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On Tue, 2017-10-17 at 18:18 +0300, Leon Romanovsky wrote:
> From: Noa Osherovich <noaos-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>
> There are root complexes that are able to optimize their
> performance when incoming data is multiple full cache lines.
>
> Scatter end padding is the device's ability to pad the ending of
> incoming packets (scatter)
I hate this naming. I'm sure people inside of Mellanox have gotten
used to it, but this feature really has no bearing on scatter/gather at
all. This is merely final write padding. You might have a
scatter/gather list, you might have a single buffer. Either way, the
PCI root complex couldn't care less about scatter/gather or not, it's
all a byte stream to it. I would be much happier with a name that
reflected what this really does.
> to full cache line such that the last
> upstream write generated by an incoming packet will be a full cache
> line.
>
> Add a relevant entry to ib_device_cap_flags to report scatter end
> padding capability of an RDMA device.
>
> Add the QP and WQ create flags with an entry for scatter end padding:
> * A QP/WQ created with a scatter end padding flag will cause
> HW to pad the last upstream write generated by a packet to cache
> line.
>
> User should consider several factors before activating this feature:
> - In case of high CPU memory load (which may cause PCI back pressure
> in
> turn), if a large percent of the writes are partial cache line,
> this
> feature should be checked as an optional solution.
> - This feature might reduce performance if most packets are between
> one
> and two cache lines and PCIe throughput has reached its maximum
> capacity. E.g. 65B packet from the network port will lead to 128B
> write on PCIe, which may cause traffic on PCIe to reach high
> throughput.
>
> Signed-off-by: Noa Osherovich <noaos-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Majd Dibbiny <majd-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> drivers/infiniband/core/uverbs_cmd.c | 3 ++-
> include/rdma/ib_verbs.h | 4 ++++
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/core/uverbs_cmd.c
> b/drivers/infiniband/core/uverbs_cmd.c
> index d31e4bc58e9a..ab29a0327831 100644
> --- a/drivers/infiniband/core/uverbs_cmd.c
> +++ b/drivers/infiniband/core/uverbs_cmd.c
> @@ -1491,7 +1491,8 @@ static int create_qp(struct ib_uverbs_file
> *file,
> IB_QP_CREATE_MANAGED_RECV |
> IB_QP_CREATE_SCATTER_FCS |
> IB_QP_CREATE_CVLAN_STRIPPING |
> - IB_QP_CREATE_SOURCE_QPN)) {
> + IB_QP_CREATE_SOURCE_QPN |
> + IB_QP_CREATE_SCATTER_END_PADDING)) {
Maybe IB_QP_CREATE_PCI_WRITE_PAD?
> ret = -EINVAL;
> goto err_put;
> }
> diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> index 9810e4568635..4c0a539cd2a2 100644
> --- a/include/rdma/ib_verbs.h
> +++ b/include/rdma/ib_verbs.h
> @@ -229,6 +229,8 @@ enum ib_device_cap_flags {
> /* Deprecated. Please use IB_RAW_PACKET_CAP_SCATTER_FCS. */
> IB_DEVICE_RAW_SCATTER_FCS = (1ULL << 34),
> IB_DEVICE_RDMA_NETDEV_OPA_VNIC = (1ULL <<
> 35),
> + /* The device supports padding incoming writes to cacheline.
> */
/* The device supports padding the final write of a PCI write
transaction to a cacheline boundry so that the PCI root complex can
optimize its memory accesses */
> + IB_DEVICE_SCATTER_END_PADDING = (1ULL << 36),
> };
>
> enum ib_signature_prot_cap {
> @@ -1098,6 +1100,7 @@ enum ib_qp_create_flags {
> IB_QP_CREATE_SCATTER_FCS = 1 << 8,
> IB_QP_CREATE_CVLAN_STRIPPING = 1 << 9,
> IB_QP_CREATE_SOURCE_QPN = 1 << 10,
> + IB_QP_CREATE_SCATTER_END_PADDING = 1 << 11,
> /* reserve bits 26-31 for low level drivers' internal use */
> IB_QP_CREATE_RESERVED_START = 1 << 26,
> IB_QP_CREATE_RESERVED_END = 1 << 31,
> @@ -1621,6 +1624,7 @@ enum ib_wq_flags {
> IB_WQ_FLAGS_CVLAN_STRIPPING = 1 << 0,
> IB_WQ_FLAGS_SCATTER_FCS = 1 << 1,
> IB_WQ_FLAGS_DELAY_DROP = 1 << 2,
> + IB_WQ_FLAGS_SCATTER_END_PADDING = 1 << 3,
> };
>
> struct ib_wq_init_attr {
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-10-25 17:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-17 15:18 [PATCH rdma-next 0/2] Introduce an IB device's scatter end padding capability Leon Romanovsky
[not found] ` <20171017151857.11934-1-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2017-10-17 15:18 ` [PATCH rdma-next 1/2] IB/core: Add scatter end padding flags for WQ and QP Leon Romanovsky
[not found] ` <20171017151857.11934-2-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2017-10-25 17:58 ` Doug Ledford [this message]
[not found] ` <1508954339.3325.45.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-10-25 19:03 ` Leon Romanovsky
[not found] ` <20171025190352.GW16127-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
2017-10-25 19:53 ` Jason Gunthorpe
[not found] ` <20171025195311.GD998-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2017-10-25 19:57 ` Leon Romanovsky
2017-10-17 15:18 ` [PATCH rdma-next 2/2] IB/mlx5: Add scatter end padding support Leon Romanovsky
[not found] ` <20171017151857.11934-3-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2017-10-18 10:37 ` Amrani, Ram
[not found] ` <BN3PR07MB25787107C19B694BB0BA39B4F84D0-EldUQEzkDQfpW3VS/XPqkOFPX92sqiQdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-10-18 13:53 ` Noa Osherovich
[not found] ` <7d53f1e2-239b-0415-5b28-875f1710c11a-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2017-10-19 7:56 ` Amrani, Ram
[not found] ` <BN3PR07MB2578139CB1C38C5228B395F6F8420-EldUQEzkDQfpW3VS/XPqkOFPX92sqiQdvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2017-10-19 10:15 ` Noa Osherovich
[not found] ` <70f59192-fcd8-95b9-72f0-edda9ac6c287-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2017-10-19 11:29 ` Amrani, Ram
2017-10-18 7:12 ` [PATCH rdma-next 0/2] Introduce an IB device's scatter end padding capability Christoph Hellwig
[not found] ` <20171018071258.GA32583-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2017-10-18 13:51 ` Noa Osherovich
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=1508954339.3325.45.camel@redhat.com \
--to=dledford-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=noaos-VPRAkNaXOzVWk0Htik3J/w@public.gmane.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