译文 | MPI newbie:What is “operating system bypass”?

原文链接:MPI newbie: What is “operating system bypass”?
顺便提一下标题那个有意思的词newbie,念成牛逼,实际上是新手的意思哈哈!OS bypass译为系统旁路。

转载请注明出处,正文开始

“OS bypass”这个术语经常会在MPI和HPC的对话中被提及,它通常被认为在许多MPI的应用中是“必备品”,因为它能提高应用的性能。
但是,它到底是什么呢?如果它对提高应用性能有帮助,那么为什么不所有应用都使用OS bypass呢?
通常访问网络硬件,比如访问Network Internet Cards[what is NICs]的模式,就是先调用用户空间的API,例如TCP socket调用包括bind、connect、accept、read、write等,然后交给操作系统,由操作系统来调用懂得如何与当前电脑中的NIC硬件交互的设备驱动。
这种模式已经被很好的验证过了,而且几乎是所有应用程序(除了HPC)的工作方式。
那么HPC应用为什么不使用这种模式呢,至少有两大原因:

  1. 这种模式需要进入到内核,横穿整个操作系统网络栈,最后停止在某个具体的设备驱动,这个过程实在是“太慢”了。这里说“慢”并不是真的慢,这种模式对于世界上99.99999%的应用来说都非常好了。但是对于短网络消息来说,它们需要超低延迟的HPC应用来看到这些操作花销的时间,并且认为,“我们可以阻止这一切”。
  2. 虽然整个HPC生态系统的要求范围非常大,但许多HPC应用程序共享一些共同特征。例如:一个运行的HPC任务不需要与各种硬件交互,不需要通过WAN通信,它通常只与一小部分peers进行通信,等等诸如此类。总之,关于一个通常的HPC应用不需要做什么这个问题可以总结的太多了,因此在操作系统中的通用网络栈是不必要的。

换个角度来说:HPC应用的专业性避免执行那些通用网络的行为,从而允许使用更小,高度专业化的,并且非常高效的网络栈(这被限制在一组具体的假设上)。
这些软件栈存在于用户空间中间件库中(比如MPI),因此可以给HPC应用提供相当高的网络I/O性能。因为这些库可以直接与NIC硬件交互,所以它们可以高效地将迷你专用“设备驱动”带入用户空间。
作为用户空间“设备驱动程序”,这种库可以直接将网络流量注入到NIC硬件中。同样的,高性能的NIC通常可以将入站的MPI流量直接引导到目标MPI进程。这意味着,它们不需要通过软件调度来引导入站流量到目标MPI进程(那么做会更慢)。
对短消息来说,通过这种方式绕过操作系统的网络栈产生的延迟超低,这也是总体HPC应用高性能表现的关键因素所在。(注意:许多HPC应用需要频繁地交换短消息)。
需要注意的是,有得必有失,在获得高性能的同时,也有一个不可避免的损失,那就是灵活性。
例如,现行的MPI库都倾向于做一些假设,关于是否能充分利用CPU内核去调度网络硬件资源来检查进度。对于每个CPU内核只有一个进程的HPC应用来说是非常好的,但是在这假设之外就非常可怕了,例如在大量超额认购的虚拟环境中

译者注:上一段emphasis部分不晓得原文啥意思,在这里提供下原文: but would be horrible outside of those assumptions (e.g., in a heavily oversubscribed virtualized environment)

此外,线路协议的互操作水平一般都很低:例如在一个运行的MPI任务中的一个个体进程,通常认为他的所有peers都使用同一种线路协议。它甚至可能认为它的所有peers都使用同一供应商的NICs,可能甚至是相同的固件版本。
诸如此类的假设导致了性能关键代码路径的简化,有助于进一步降低短消息的延迟。
因为这些因素,系统旁路技术,代码路径简化和其他一些优化都通常一起出现,而且只适用于许多假设和限制的受控环境下。所以这就是为什么系统旁路技术只适用于HPC应用而根本不适用于通用的网络应用程序。
完。