
Комментарии 6
а как эта штука показывает себя по сравнению с аналогами? ну там latency и пропускная способность
Пока не проводил корректное сравнение с аналогами на одинаковом стенде. Производительность сильно зависит от режима работы (XDP native/generic) и сложностью логики обработки, характером трафика и особенностями оборудования. В одном из следующих этапов планирую провести бенчмарки с измерением latency, PPS, throughput и загрузки CPU, а также сравнить поведение на RISCV и x86-64. К сожалению, ARM-платформы для тестирования у меня пока нет. Результаты планирую оформить в отдельную публикацию.
А как с гонками разбираться, если налету мапы политик обновлять?
Сами BPF maps безопасны для конкурентного доступа: control plane может обновлять map, пока dataplane её читает. В текущей реализации при изменении существующей политики я не создаю новый набор связанных правил - сначала выполняется поиск политики по её ключу, после чего изменяется значение этого же элемента map. Например, при изменении действия с Drop на Allow меняется значение существующей записи.
Поэтому на уровне одной ACL-записи нет состояния, в котором dataplane может увидеть «половину» обновления: пакет либо обрабатывается по старым данным, либо после обновления - по новым. При этом пакет, который уже находится в процессе обработки, естественно, может завершиться по старому состоянию.
что с поддержкой таблицы состояний, типа того же conntrack. :) какова ценность решения без таковой(?).
Ценность есть но не сейчас . В ходе пересмотра архитектуры состояния "минимально живого продукта "- порезал функционал и это было осознанно ,для того чтобы выделить - что живое и можно показать людям с примерами ,а что нужно пересмотреть и переделать . Да признаю,что хвосты остались . Но можно считать ,что это "заготовки" под будущий функционал ,например под Load balance ,*NAT и тд... Который будет в ближайшее время реализован .
Pulsar. eBPF-based programmable networking dataplane (Статус: MVP)