[EMAIL PROTECTED] wrote on Wed, 18 Oct 2006 15:09 -0500:
> The solution for a kernel hacker like me is obvious, you allow the OS
> kernel memory management and network driver handle the memory pinning
> and interaction with the hardware. This way an application can just
> call the OS to register the entire application memory space, and the
> OS kernel can deal with keeping it all pinned down, and if it needs
> to unpin something, it can do so.
>
> The catch is that it requires the hardware to support keeping an
> address registered, but *not* physically pinned, and *ask nicely* to
> the OS via the page fault handler to pin the page back down if
> something comes in. This seems to be an idea that RDMA hardware
> designers just can't wrap their heads around. I guess they are too
> used to dealing with OS'es that never change.
Yes, certainly. We can call this the "Quadrics method". You're
essentially managing the NIC as another CPU with its own set of
TLBs. Beyond the problem of getting such a mechanism accepted by
current kernel developers, it has other issues that complicate life
for a NIC design. What happens to the packet if you find the page
isn't ready? Drop it on the floor and let retransmit deal with it?
Buffer it and all future packets flying in at 30 GB/s into NIC
memory? This problem complicates flow control in such interesting
ways that the idea never got into the final IB or iWarp specs, for
instance. It's worth investigating for future designs, agreed, but
we're stuck without it for current network cards.
-- Pete
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
