Расчёт CRC в кадре и про аппаратное его ускорение

Пост в котором будет про crc 32. (пасхалка)

В конце 2008 года компания Intel представила архитектуру Nehalem и ядро Bloomfield построенное на ней с использованиям 45 нм.

Всё это камни известные под брендом i7.

Из того, на что (сетевому инженеру) следует обратить внимание - это добавленная в архитектуре поддержка команд набора SSE 4.2. Набор этих инструкции по-другому называется программно-ориентированные ускорители (Application Targeted Accelerator) и служит вполне себе прикладным целям. Одна из команд этого набора нам будет особенно интересна.

Речь пойдёт про инструкции для аппаратного ускорения CRC32.

За аббревиатурой CRC (Циклический избыточный код - Cyclic redundancy check) - скрывается механизм проверки целостности данных, встроенный, в том числе, в Ethernet. Каждый кадр пролетающий по современным сетям всегда проверяется на два аспекта, до того как быть признанным «здоровым» кадром.

Первое, что делает каждое l2 устройство, на пути следования кадра - проверяет целочисленное деление количества бит в кадре на 8.

Если поделить "нацело" не получилось - кадр плохой, делать с ним ничего не нужно. Его нужно только выбросить.

Второе (а на самом деле, полуторное) - это, собственно, подсчёт CRC32.

По мере "влетания" бит в порт, для каждого блока из 32 бит начиная от SFD (начала кадра - или, другими словами, последнего блока в преамбуле, о которой я уже писал раньше), начинает вычисляться контрольная сумма. Заканчивается это вычисление за 32 бита до конца кадра - за 32 бита до "прилетания" EFD (End Frame Delimiter) в порт. Последние 32 бита в кадре, как не сложно догадаться, это исходная CRC32, которую вычислил отправитель и с которой сейчас будет происходить сравнение результата. Называется этот, последний блок данных в кадре - FCS (Frame Check Sequences).

Хозяйке на заметку:

* Вычисление происходит поточно, начиная с первых бит кадра. Это позволяет «размазать» вычисления и затраты вычислительных ресурсов во времени.

* Если железка умеет работать на "сверх ускорении" - то та часть кадра, для которой уже было посчитано CRC сразу же улетают в порт доставки, и даже если CRC не сошлось - сделать с кадром ничего нельзя. "Он улетел, но обещал вернуться" (нет)

* Вычисление происходи параллельно с проверкой на целочисленное деление количества бит на 8 (или, проще, все биты превращаются в байты). Деление заканчивается раньше, потому ошибку framing error вы получаете раньше, чем ошибку crc, даже если, формально, для такого кадра присутствуют оба вида ошибок. (ошибки crc в этом случае вообще посчитано не будет)

* Редакция 32 была выбрана не случайно, именно такой способ показывал наименьшее количество ложно-позитивных срабатываний на большинстве сценариев внутри Ethernet. Если проще - именно crc32 лучше всего подходит для проверки, чем что-то другое.

* Все эти вычисления, чаще всего, делает сетевая карта, если она есть. А если её нет (например, в виртуальных машинах) делает процессор...

...и вот в 2008 году появляется процессор, в архитектуре которого, крупно, было заявлено ускорение расчётов CRC32. Это означало существенное ускорение обработки трафика для всех систем виртуализации на платформе Intel - так по-крайней мере, рассказывалось маркетологами на различных конференциях*.

Однако, никто не читает текст под звёздочками.

Всё дело в том, что инструкции из набора SSE 4.2 ускоряют только определённый, вполне конкретный тип проверки целостности - CRC32c. Он же по-другому (один из вариантов) называется CRC32-ISCSI.

*К сожалению, к Ethernet механизм CRC32c никак не относится. Т.е., несмотря на былые заверения маркетологов Майкро… некоторых маркетологов их гипервизард не станет быстрее обрабатывать трафик на процессорах этой или более новых архитектур.

Stay connected and checksum offload enable.

https://t.me/cooladmin