From: Yann Droneaud <ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Roland Dreier <roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org>,
Animesh K Trivedi1
<ZRLATR-Xeyd2O9EBijQT0dZR+AlfA@public.gmane.org>,
Bernard Metzler <BMT-OA+xvbQnYDHMbYB6QlFGEg@public.gmane.org>
Subject: Re: (R)DMA in userspace
Date: Fri, 12 Oct 2012 16:55:40 +0200 [thread overview]
Message-ID: <1350053740.9068.1.camel@test.quest-ce.net> (raw)
In-Reply-To: <1350033163.2291.22.camel-sQn2kEGNn0pFevvuwOF9vF6hYfS7NtTn@public.gmane.org>
Le vendredi 12 octobre 2012 à 11:12 +0200, Yann Droneaud a écrit :
> 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-0BZ7OvD7h6o@public.gmane.orgcom> 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.
>
I've found more information in "Implementing DMA on ARM SMP Systems",
Application Note 228
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0228a/index.html
ARMv7 Cortex-A9 seems to be a cache-coherent architecture.
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
prev parent reply other threads:[~2012-10-12 14:55 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
[not found] ` <1350033163.2291.22.camel-sQn2kEGNn0pFevvuwOF9vF6hYfS7NtTn@public.gmane.org>
2012-10-12 14:55 ` Yann Droneaud [this message]
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=1350053740.9068.1.camel@test.quest-ce.net \
--to=ydroneaud-rly5vtjfyj3qt0dzr+alfa@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.