Эволюция архитектуры виртуального интерфейса

Рис. 2. Архитектура доступа к системной памяти. Системная память, в которую загружены два приложения, осуществляющие доступ к сети с использованием сетевого интерфейса уровня пользователя. Обычный драйвер устройств операционной системы управляет аппаратными средствами интерфейса. Драйвер устройств обеспечивает прямой доступ приложений к интерфейсу. Приложения выделяют буферы в собственном адресном пространстве и при помощи интерфейса пересылают информацию сообщений в буферы и в обратном направлении, используя механизм прямого доступа к памяти (direct memory access, DMA).

На рис.2 показана системная память, в которой находятся два приложения, осуществляющие доступ к сети при помощи сетевого интерфейса пользовательского уровня. Драйвер устройств операционной системы управляет аппаратными средствами интерфейса традиционным способом, осуществляя контроль за доступом приложений к оборудованию. Приложения выделяют буферы сообщений в собственном адресном пространстве и обращаются к драйверу устройств для получения доступа к сетевому интерфейсу. После соответствующей настройки они автоматически инициируют процесс передачи и приема, а интерфейс пересылает информацию в буферы приложений и в обратном направлении, используя обычный механизм прямого доступа к памяти. Архитектура сетевого интерфейса пользовательского уровня варьируется в зависимости от особенностей конкретных приложений и сетей — от способа определения приложениями местоположения пересылаемых сообщений, от местонахождения выделяемых для приема информации буферов, от порядка уведомления приложений о поступивших сообщениях. В некоторых сетевых интерфейсах (например, в интерфейсах Active Message или Fast Message) операции передачи и приема реализованы в виде функций, помещенных в пользовательскую библиотеку, которая загружается при инициализации каждого процесса. В других (например, в U-NET и VIA) для каждого процесса создаются очереди, которыми манипулируют сами приложения. Эти очереди обслуживаются аппаратными средствами интерфейса.

Сетевые интерфейсы пользовательского уровня, базирующиеся на сообщениях, создавались на основе традиционных моделей передачи сообщений между компьютерами. В этих моделях отправитель определяет адрес памяти источника данных и узел конечного процессора, а получатель в явной форме пересылает входящие сообщения в область памяти адресата. Учитывая семантику операций передачи и приема, библиотека сетевого интерфейса пользовательского уровня должна либо буферизовать сообщения (в этом случае они пересылаются через промежуточный библиотечный буфер), либо обеспечить поддержку дорогостоящего коммуникационного канала между отправителем и получателем, своевременно уведомляя их о судьбе каждого сообщения. В обоих случаях накладные расходы слишком велики. Интерфейс Active Message [4] создавался именно для того, чтобы уменьшить эти накладные расходы. Данная концепция основывалась на использовании примитивов, с помощью которых можно было эффективно реализовать на практике все многообразие коммуникационных операций. Основная идея заключалась в том, чтобы поместить в каждое сообщение адреса отвечающих случаю обработчиков, после чего заставить сетевой интерфейс вызывать нужные обработчики при получении соответствующих сообщений. Размещение обработчика в сообщении привело к повышению быстродействия процедур управления: во время выполнения клиентского кода данные каждого сообщения эффективно взаимодействовали с окружающей вычислительной средой.

От протокола Active Message не требовалось буферизации сообщений. Он строился на основе обработчиков, которые непрерывно извлекали сообщения из сети. В различных версиях Active Message не предусматривались возможности управления потоками и ретрансляции сообщений, поскольку все эти механизмы уже были реализованы в связывающей параллельные машины сети. Хотя протокол Active Message неплохо отвечал потребностям первого поколения коммерческих компьютеров с массовым параллелизмом, непосредственное обслуживание полученных сообщений процессорами с многоступенчатыми конвейерами с течением времени все более и более осложнялось. Авторы некоторых версий попытались реализовать обработчики в виде прерываний, но слишком высокая стоимость такого решения заставила их прибегнуть сначала к скрытому, а затем и к явному опросу в конце процесса передачи. Таким образом, вновь встал вопрос о непроизводительных издержках. Проведение опроса вызывало возникновение задержек еще до обнаружения поступившего сообщения и приводило к накладным расходам, даже если сообщений не было.

Появление протокола Fast Message [5] позволило решить все возникшие вопросы за счет замены процедур обработки буферизацией и проведения явного опроса. При помощи буферизации удалось отложить запуск обработчиков в тех случаях, когда функции сетевого обслуживания не поддерживались, у приложений же была уменьшена частота проведения опроса, что в свою очередь привело к снижению издержек. Операция передачи определяла узел назначения, обработчик и местоположение данных. Согласно концепции Fast Message сообщения передавались и помещались в буфер на приемной стороне. При приеме вызова получателем протокол Fast Message запускал обработчики всех незавершенных сообщений.

Таблица. Быстродействие процедур подтверждения приема стандартных сокетов и сетевых интерфейсов уровня пользователя в сети Myricom Myrinet

В случае перемещения процедуры буферизации обратно на уровень сообщений она оптимизировалась в соответствии с особенностями машины-получателя и обрабатывалась функциями управления потоком, которые помогали избежать тупиковых ситуаций и обеспечивали надежную связь в неустойчивых сетях. Высокая эффективность буферизации коротких пакетов на уровне сообщений была доказана на практике (эти решения нашли отражение в версии протокола Active Message II, AM II). Сообщения в этом случае пересылались адресату без использования буферов.

Технология U-Net стала первой разработкой, которая коренным образом отличалась как от Active Message, так и от Fast Message. В табл.1 показана производительность протокола U-Net и четырех последующих реализаций сети Myricom Myrinet [6]. Технология U-Net поддерживает сетевой интерфейс, который по своему функциональному назначению близок к аппаратной реализации интерфейса локальных сетей. В этом случае не выделяется никаких буферов. Буферизация сообщений организована в неявном виде, все сообщения находятся под контролем. Вместо вызова функций API-интерфейса (как это было в прежних интерфейсах) в памяти организуется набор очередей, через которые сообщения и пересылаются. В сущности протоколы Active Message и Fast Message определяют тонкий слой программного обеспечения, который отвечает за поддержку унифицированного интерфейса с оборудованием сети. Со своей стороны, интерфейс U-Net специфицирует аппаратные операции, посредством которых оборудование предоставляет стандартный интерфейс непосредственно программному обеспечению пользовательского уровня.

Рис. 3. Архитектура U-Net. Каждое приложение получает доступ к сети через конечные точки U-Net. В конечной точке находятся очереди передачи и приема, а также свободная очередь, которые указывают на буферы, выделенные приложением. Аппаратные средства интерфейса обращаются к очередям, чтобы определить, какой буфер пересылает сообщения внутрь, получателю (получение через DMA) и за пределы системы (отправка через DMA).

Технология U-Net хорошо подходила к кластерной среде, в которой использовались стандартные сетевые технологии (например, Fast Ethernet или ATM). Сеть должна была не только поддерживать параллельную обработку, но и обеспечивать традиционное потоковое взаимодействие. Машины внутри кластера взаимодействовали с внешними узлами при помощи тех же самых сетевых средств.

Архитектура. В технологии U-Net конечные точки содержат три очереди сообщений (см. рис. 3). В очередях хранятся дескрипторы для буферов сообщений, подготовленных к отправке (очередь на отправку), буферов, освобожденных для получения сообщений (свободная очередь), и буферов уже полученных сообщений (очередь на получение). При отправке сообщения обработчик помещает дескриптор в очередь на отправку. Дескриптор содержит указатели на буферы сообщения, их длину и адрес назначения. Сетевой интерфейс извлекает дескриптор, проверяет его адрес назначения, преобразует адреса виртуальных буферов в физические адреса и пересылает данные при помощи механизма прямого доступа к памяти (DMA, direct memory access).

При приеме сообщения сетевой интерфейс извлекает из заголовка корректную конечную точку адресата, удаляет нужные дескрипторы из соответствующей свободной очереди, транслирует их виртуальные адреса, пересылает данные в память, используя механизм DMA, и помещает дескриптор в очередь на получение в конечной точке. Приложение может обнаружить поступившее сообщение путем опроса очереди на получение, установления блокировки до поступления сообщения (как при вызове системного вызова select в ОС Unix) или при получении асинхронного уведомления (например, сигнала) о поступлении сообщения.

Защита. В протоколе U-Net процессы, получающие доступ к сети на сервере, защищены друг от друга. Механизм U-Net помещает очередь в каждой конечной точке только в адресное пространство того процесса, который владеет данной конечной точкой. При этом все адреса являются виртуальными. Протокол U-Net следит за тем, чтобы процессы не отправляли сообщения по произвольным адресам, и предотвращает прием сообщений, предназначенных для других адресатов. По этой причине процессы должны предварительно настроить коммуникационные каналы перед отправкой и приемом сообщений. Каждому каналу ставится в соответствие конечная точка, определяется адресный шаблон как для исходящих, так и для входящих сообщений. Когда процесс создает канал, операционная система проверяет шаблоны, чтобы гарантировать выполнение нужной стратегии для всех исходящих сообщений и обеспечить однозначное соответствие между входящими сообщениями и конечной точкой получателя.

При работе с протоколом U-Net, напротив, в памяти должны оставаться только точки входа в интерфейсный буфер TLB. Интерфейс может удалить из памяти схему расположения приложений, не использующих сетевые буферы, создавая, таким образом, необходимые условия для разбиения памяти на страницы и размещения в ней обычных приложений.

Сетевой интерфейс пользовательского уровня должен распаковывать поступающие сообщения и помещать их в очередь на получение. При отправке сообщений интерфейс обязан обеспечить требуемый уровень защиты (например, путем проверки адресной информации). Сложность обеих операций во многом зависит от типа используемой сети.

Технология мультиплексирования VIA ориентирована исключительно на соединения. До начала процедуры передачи данных между двумя виртуальными интерфейсами обязательно должна быть установлена связь. В спецификациях не описываются детали представления соединения на сетевом уровне, поэтому интерфейс VIA может работать поверх Ethernet и даже поверх протокола IP, определив предварительно порядок подтверждения установления связи между конечными точками и используя специальное поле для поддержки различных соединений.

Учитывая особенности соединения VIA, приложения, работающие в сетях VIA, не могут взаимодействовать с приложениями других сетей. К примеру, серверный кластер, использующий внутреннее соединение VIA для организации взаимодействия с клиентами за пределами кластера, должен применять обычные сетевые интерфейсы.

Протокол U-Net обеспечивает большую гибкость процессов мультимлексирования и демультиплексирования. В среде Fast Ethernet сетевой интерфейс реализует полный пакетный фильтр, который не ориентирован на соединения. Когда приложение открывает коммуникационный канал, оно определяет шаблоны для анализа заголовков входящих и исходящих пакетов. Агент ядра проверяет шаблоны, чтобы исключить конфликты с другими приложениями и размещает их в уплотненных структурах данных. Технология обработки пакетов U-Net обеспечивает возможность взаимодействия с общим стеком протокола, а также поддерживает отправку и прием многоадресных сообщений.

Процедура фильтрации должна быть реализована в виде динамического анализатора пакетов, совместимого с различными сетевыми протоколами и соответствующего природе полей идентификаторов, не имеющих фиксированной позиции в сообщении. К пакетному фильтру предъявляются более жесткие требования, нежели ранее, поскольку иного пути передачи неопознанных пакетов ядру операционной системы просто не существует. Безопасный маршрут больше не воспринимается как опция, потому что задача управления интерфейсными очередями на получение возлагается на операционную систему. Версия протокола U-Net для Fast Ethernet справляется с этой проблемой при помощи стандартного сетевого интерфейса и встраивания дополнительных функций в обработчик прерываний. Соответственно пакетный фильтр не отличается особой сложностью.

Управление чтением и записью при помощи механизма RDMA усложняет реализацию архитектуры VIA. При записи принимаемого сообщения интерфейс должен не только правильно определить местонахождение VI, но и извлечь из сообщения целевой адрес памяти, преобразовав его при этом к нужному виду. Основная трудность здесь заключается в том, чтобы корректно обработать ошибки процедуры управления передачей. Интерфейс обязан проверить контрольную сумму пакета, прежде чем данные будут записаны в память. В этом случае гарантируется целостность данных в конечной точке маршрута. Проверить это непросто, потому что в большинстве сетей контрольная сумма находится в конце пакета, и интерфейс вынужден полностью разместить пакет в буфере еще до начала передачи данных в основную память через канал DMA. Альтернативный вариант — включение в заголовок отдельного поля для контрольной суммы.

Чтение через канал RDMA тоже не всегда протекает гладко. Сетевой интерфейс за короткий промежуток времени может получить больше запросов на чтение, чем способен обслужить. В этом случае запросы для последующей обработки помещаются в очередь. Если очередь переполняется, запросы отбрасываются. Чтобы обеспечить надежное чтение через канал RDMA, интерфейс VIA ограничивает механизм реализации запросов на чтение процедурами, гарантирующими надежную доставку.

Разработчики технологии VIA, проанализировав существующие сетевые интерфейсы пользовательского уровня, почерпнули для себя немало полезного и успешно завершили проектирование согласованных спецификаций. Пользователи, которым удалось познакомиться с этими исследованиями, смогли без особого труда адаптироваться к особенностям VIA и остались довольны возможностями коммерческих аппаратных средств. Но поскольку основной областью применения архитектуры VIA стали серверные сети, нельзя не упомянуть об одном существенном упущении разработчиков по сравнению с технологией U-Net: интерфейс VIA не может взаимодействовать с серверами, которые используют обычные сетевые интерфейсы.

Чтобы извлечь максимальную выгоду из сочетания интерфейса VIA с высокоскоростными сетевыми технологиями, требуются дополнительные исследования, которые помогут найти пути проектирования протоколов с малым временем задержки, упорядочения объектов при минимальных затратах, создать эффективные синхронизирующие механизмы для протоколов, определить оптимальный график установления связи и управления сетевой памятью. Наиболее серьезные изменения затронут механизм управления памятью. Буферы UTLB модели VMMC-2 и архитектура VIA просты в реализации, но отбирают дополнительные ресурсы у общего страничного пула. Буфер TLB интерфейса U-Net поддерживает тесное взаимодействие с операционной системой и реализует справедливый механизм управления памятью, но данный подход является более дорогостоящим и потребует дополнительных затрат в случае потери информации.

Таким образом, несмотря на то, что сегодня сетевые интерфейсы пользовательского уровня VIA доступны каждому, конструкторам придется еще немало потрудиться, прежде чем разработчики приложений смогут забыть о головной боли. Впрочем, в конце концов, исследователи наверняка справятся с возникшими препятствиями, а пользователи сумеют освоить особенности VIA.

ОБ АВТОРАХ

Thorsten von Eiken, Werner Vogels, Evolution of Virtual Interface Architecture. IEEE Computer, November 1998, pp. 61-68. Reprinted with Permission, Copyright IEEE CS, 1998, All rights reserved.

От качества управления интегрированным буфером, который создается между приложением и сетевым интерфейсом, зависит возможность исключить избыточное копирование данных, а также эффективность выделения и освобождения ресурсов

Технология мультиплексирования VIA ориентирована исключительно на соединения. До начала процедуры передачи данных между двумя виртуальными интерфейсами обязательно должна быть установлена связь

Литература

[1] D.Dunning et al., «The Virtual Interface Architecture», IEEE Micro, Mar-Apr. 1998, pp. 66-76.

[2] T.von Eicken et al., «U-Net: A User-level Network Interface for Parallel and Distributed Computing», Proc.15th Symp. Operating Systems Principles, ACM Press, New York, 1995, pp.40-53.

[3] W.Vogels et al., «Scalability of the Microsoft Cluster Service», Proc. Second Usenix Windows NT Symp., Usenix Assoc., Berkeley, Calif., 1998, pp.11-19.

[4] T.von Eicken et al., «Active Messages: A Mechanism for Integrated Communication and Computation», Proc. 19th Symp. Computer Architecture, IEEE CS Press, Los Alamitos, Calif., 1992, pp.256-266.

[5] S.Pakin, M.Lauria, and A.Chien, «High Performance Messaging on Workstations: Illinois Fast Messages (FM) for Myrinet», Proc. Supercomputing?95, ACM Press, New York, 1995.

[6] N.J.Boden et al., «Myrinet: A Gigabit-per-Second Local Area Network», IEEE Micro, Feb. 1995, pp.29-36.

[7] B.N.Chun, A.M.Mainwaring, and D.E.Culler, «Virtual Network Transport Protocols for Myrinet», IEEE Micro, Jan.-Feb. 1998, pp.53-63.

[8] M.Blumrich et al., «Virtual-Memory-Mapped Network Interfaces», IEEE Micro, Feb. 1995, pp.21-28.

[9] C.Dubnicki et al., «Shrimp Project Update: Myrinet Communication», IEEE Micro, Jan.-Feb. 1998, pp.50-52.

[10] M.Welsh et al., «Memory Management for User-Level Network Interfaces», IEEE Micro, Mar.Apr., 1998, pp.77-82.

[11] M.Bailey et al., «Pathfinder: A Pattern Based Packet Classifier», Proc. Symp. Operating Systems Design and Implementation, Usenix Assoc., Berkekey, Calif., 1994, pp.115-123.