diff options
| author | Chuck Lever <chuck.lever@oracle.com> | 2016-09-15 10:56:10 -0400 |
|---|---|---|
| committer | Anna Schumaker <Anna.Schumaker@Netapp.com> | 2016-09-19 13:08:37 -0400 |
| commit | 99ef4db329f1ee2413dad49346e72a6c902474d1 (patch) | |
| tree | e1ba252d10de1bac6fe4ad83b4a6f5339a3d235d /net/sunrpc/xprtrdma/rpc_rdma.c | |
| parent | 08cf2efd5423121985af5962d66e6db14dff4130 (diff) | |
| download | linux-99ef4db329f1ee2413dad49346e72a6c902474d1.tar.gz linux-99ef4db329f1ee2413dad49346e72a6c902474d1.tar.bz2 linux-99ef4db329f1ee2413dad49346e72a6c902474d1.zip | |
xprtrdma: Replace DMA_BIDIRECTIONAL
The use of DMA_BIDIRECTIONAL is discouraged by DMA-API.txt.
Fortunately, xprtrdma now knows which direction I/O is going as
soon as it allocates each regbuf.
The RPC Call and Reply buffers are no longer the same regbuf. They
can each be labeled correctly now. The RPC Reply buffer is never
part of either a Send or Receive WR, but it can be part of Reply
chunk, which is mapped and registered via ->ro_map . So it is not
DMA mapped when it is allocated (DMA_NONE), to avoid a double-
mapping.
Since Receive buffers are no longer DMA_BIDIRECTIONAL and their
contents are never modified by the host CPU, DMA-API-HOWTO.txt
suggests that a DMA sync before posting each buffer should be
unnecessary. (See my_card_interrupt_handler).
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Diffstat (limited to 'net/sunrpc/xprtrdma/rpc_rdma.c')
0 files changed, 0 insertions, 0 deletions