From: Yann Droneaud <yann-WYdEh2jsUj5Wj0EZb7rXcA@public.gmane.org>
To: Roland Dreier <roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org>
Cc: Animesh K Trivedi1
<ZRLATR-Xeyd2O9EBijQT0dZR+AlfA@public.gmane.org>,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Bernard Metzler <BMT-OA+xvbQnYDHMbYB6QlFGEg@public.gmane.org>
Subject: Re: (R)DMA in userspace
Date: Fri, 12 Oct 2012 11:12:43 +0200 [thread overview]
Message-ID: <1350033163.2291.22.camel@test.quest-ce.net> (raw)
In-Reply-To: <CAL1RGDUOMz7Qf8bX7hZpJgARGepLQRwY25f6Q1utYBZ0taMs9A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
Le jeudi 11 octobre 2012 à 13:44 -0700, Roland Dreier a écrit :
> On Thu, Oct 11, 2012 at 8:34 AM, Animesh K Trivedi1 <ZRLATR-Xeyd2O9EBihhl2p70BpVqQ@public.gmane.orgm> wrote:
> >
> > During memory memory registration, userspace buffers also go through same
> > API calls (dma_map_sg_attrs(...)).
> > What I am confused about why no such synchronization primitives are
> > required in userspace before accessing
> > an RDMA data buffer just after when an incoming write/recv (DMA on it) is
> > finished? Who guarantees data
> > freshness?
>
> No one has really ever tried to deal with the issue of userspace RDMA on
> a cache-incoherent architecture. Basically if you try the current stack, the
> in-kernel users (IPoIB etc) should be OK but libibverbs etc. will be completely
> broken.
>
With the current ARMv7 Cortex-A9 / Cortex-A15 MPCore and the upcoming
ARM 64 bits architecture eg ARMv8 aka Aarch64, one might want in the
near future use RDMA (InfiniBand/RoCE) with them to create highly
parallel system with low-power consumption.
But this question and some reading about ARM memory management makes me
feel pretty unsure of the ability to use RDMA (InfiniBand) on ARM.
In this article: "ARM, DMA, and memory management"
http://lwn.net/Articles/440221/"
it is said that a memory page must not be mapped multiple time with
different caching attributes.
This article take the point of Linaro's developers who want to upload
texture to the GPU without holding them in caches. This behavior might
also be applicable to RDMA as well: writing to a memory zone to be
either local IBV_WR_SEND, local IBV_WR_RDMA_WRITE or remote
IBV_WR_RDMA_READ, there's probably no need to keep it in cache.
You could also read this other article "CMA [contiguous memory
allocator] and ARM" http://lwn.net/Articles/450286/
and "ARM's multiply-mapped memory mess" http://lwn.net/Articles/409689/
After reading this, and not being an ARM expert, I'm asking myself about
a possible RDMA (InfiniBand) support on ARM.
Regards.
--
Yann Droneaud
OPTEYA
--
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:[~2012-10-12 9:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-11 15:34 (R)DMA in userspace Animesh K Trivedi1
[not found] ` <OF84B00CFA.7F1CDA02-ONC1257A94.00545627-C1257A94.0055881A-Xeyd2O9EBijQT0dZR+AlfA@public.gmane.org>
2012-10-10 7:36 ` Isaac Huang
2012-10-11 20:44 ` Roland Dreier
[not found] ` <CAL1RGDUOMz7Qf8bX7hZpJgARGepLQRwY25f6Q1utYBZ0taMs9A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-10-11 21:04 ` Or Gerlitz
[not found] ` <CAJZOPZJiEj7rMjF1ouukCPAGCXaNBhHoG1-YuDfEikvM-LLrXg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-10-12 8:54 ` Animesh K Trivedi1
2012-10-12 23:10 ` Jason Gunthorpe
2012-10-12 9:12 ` Yann Droneaud [this message]
[not found] ` <1350033163.2291.22.camel-sQn2kEGNn0pFevvuwOF9vF6hYfS7NtTn@public.gmane.org>
2012-10-12 14:55 ` Yann Droneaud
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=1350033163.2291.22.camel@test.quest-ce.net \
--to=yann-wydeh2jsuj5wj0ezb7rxca@public.gmane.org \
--cc=BMT-OA+xvbQnYDHMbYB6QlFGEg@public.gmane.org \
--cc=ZRLATR-Xeyd2O9EBijQT0dZR+AlfA@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=roland-BHEL68pLQRGGvPXPguhicg@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