Alan> For most drivers properly, but you are making assumptions
Alan> again. Why can't a driver which is doing its own mapping not
Alan> also do its own rdma cookie handling ? You opt out of
Alan> mapping being done for you, then you get opted out of
Alan> defaults for other stuff too.
You're right, and that was what I was driving at in my earlier message
when I talked about overriding the dma mapping operations for a
device. That would let ipath or whatever create its own RDMA cookies,
and keep track of the struct page or kernel virtual address of the
original memory, so it can do memcpy when needed.
I don't think the idea lets you push mapping down into the low-level
driver, though. Take the SRP initiator as a specific example. The
SCSI midlayer gives SRP a SCSI command to send. The SRP initiator
formats that into an SRP message, with a "memory descriptor" (address
and RDMA cookie) for the buffer associated with the SCSI command, and
tells the low-level driver to send that message to the target. The
target then performs RDMA into that buffer, sending back only the RDMA
cookie and address.
So unless you teach every low-level driver how to snoop inside SRP
messages (along with NFS/RDMA, iSER and all the other protocols), I
don't see where the low-level driver has a chance to do the mapping.
- R.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
