>>> И не особенно-то это и просто покажется, если на минутку заглянуть в ядерный код.
>> Не нужно, в случае DPDK он не участвует в обработке потока данных.
> я и говорю - ты весь этот код (ну, во всяком случае,
> изрядную его часть) будешь переписывать - или, что более вероятно, оно
> будет работать только в локальной сеточке у разработчика, и на соседнем
> столе в лаборатории - а в других сетапах как-то иногда) Ну переписывать я точно не буду, разве-что поправлю при необходимости, ибо чуток участвовал.
Но начинать надо с RTFM, т.е. с понимания, что оно умеет и как работает в тех или иных случаях.
Если уж совсем кратко, то http://seastar.io/networking/ позволяет выбрать между ядерным TCP и собственным упрощенным TCP-стеком (который дружит и с DPDK и с Virtio).
//offtopic: Но в отличии моего 1Hippeus (сейчас заброшенного) не умеет эффективных очередей в разделяемой памяти (в пределах физического сервера, сквозь все слои виртуализации).
Поэтому в теплично-контролируемых условиях одного датацентра, одной стойки с серверами или внутри одного VM-хоста, можно подключаться к ScyllaDB через DPDK и упрощенный TCP без участия ядра), а в остальных случаях через штатный TCP (со всеми фичами и плюшками).
Грубо говоря, ничего не отнимается, а только добавляется.
>> нет, это "не вопрос" - работает, давно, и многократно быстрее.
> есть у меня подозрение, что это не из-за привязки к cpu и
> обработки tcp в волшебной сиплюсплюсичке, а вопреки этому.
А земля плоская?
Если серьезно, то благодаря, но далеко не только этому.
Главный тезис - просто не делать лишнего, т.е. избавить машину от ненужных фрикций.
> ну просто потому что трудно поверить универсального спеца по базам данных, умеющего
> low level tcp - причем хорошо, а не абы как.
> Обычно это сильно разные ребята.
Но не всегда ;)
