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