Address translation mechanisms in network interfaces

I. Schoinas, M.D. Hill
<i title="IEEE Comput. Soc"> <a target="_blank" rel="noopener" href="https://fatcat.wiki/container/n7ljjecrpje5pj66pk4pvx65qu" style="color: black;">Proceedings 1998 Fourth International Symposium on High-Performance Computer Architecture</a> </i> &nbsp;
Good network hardware performance is often squandered by overheads for accessing the network interface (NI) within a host. NIs that support user-level messaging avoid frequent operating system (OS) action yet unnecessary copying can still result in low performance. We explore improving application messaging performance by eliminating all unnecessary copies (minimal messaging). For minimal messaging, NIs must support address translation and must do so more richly than has been done in the past.
more &raquo; ... I address translation should flexibly support higher-level abstractions, map all user space, exploit translation locality, and degrade gracefully when locality is poor. We classify NI address translation implementations based on where the lookup and the miss handling are performed (CPU or NI). We present alternative designs and we consider how they interact with the OS. We provide simulation results that evaluate the alternative design points and we demonstrate feasibility with a real implementation using Myrinet. We find: (a) NIs need not have hardware lookup structures, as software schemes are fast enough; (b) it is difficult for an NI to handle its own translation misses unless commercial operating systems are substantially modified to view an NI as CPU peer; (c) in the conventional situation where the operating system views the NI as a device, minimal messaging should be used only when the translation is present, while a single-copy protocol is used when it is not and (d) alternatively, one can currently get acceptable performance when the CPU handle misses if the kernel provides very fast trap interfaces but microprocessor and operating system trends may make this alternative less viable in the long run.
<span class="external-identifiers"> <a target="_blank" rel="external noopener noreferrer" href="https://doi.org/10.1109/hpca.1998.650561">doi:10.1109/hpca.1998.650561</a> <a target="_blank" rel="external noopener" href="https://dblp.org/rec/conf/hpca/SchoinasH98.html">dblp:conf/hpca/SchoinasH98</a> <a target="_blank" rel="external noopener" href="https://fatcat.wiki/release/5skqlqifpnd7rhzcq23r7omzgq">fatcat:5skqlqifpnd7rhzcq23r7omzgq</a> </span>
<a target="_blank" rel="noopener" href="https://web.archive.org/web/20060901153227/http://ftp.cs.wisc.edu/wwt/hpca98_nitrans.pdf" title="fulltext PDF download" data-goatcounter-click="serp-fulltext" data-goatcounter-title="serp-fulltext"> <button class="ui simple right pointing dropdown compact black labeled icon button serp-button"> <i class="icon ia-icon"></i> Web Archive [PDF] <div class="menu fulltext-thumbnail"> <img src="https://blobs.fatcat.wiki/thumbnail/pdf/eb/96/eb965839f34bea5ccc45c56af42bd3e8f0b0d4f1.180px.jpg" alt="fulltext thumbnail" loading="lazy"> </div> </button> </a> <a target="_blank" rel="external noopener noreferrer" href="https://doi.org/10.1109/hpca.1998.650561"> <button class="ui left aligned compact blue labeled icon button serp-button"> <i class="external alternate icon"></i> ieee.com </button> </a>