Если вопрос относительно POSIX stack, то seastar сильно много сверху не добавляет, а фактически передает управление в Linux.
Если речь про native stack, то можно посмотреть с двух сторон: 1) волков бояться — в лес не ходить :) хорошо что open-source, можно будет баг завести, либо самим починить 2) native stack можно просто не использовать, заменив чем-то другим.
Однако при выборе я бы не исходил из слишком уж больших опасений по поводу безопасности, потому что строго говоря, любая реализация может быть с багами, так что полагать, что у seastar их больше, чем у других - опрометчиво.
Уверенности придают кейсы использования этого фреймворка, а так же авторитетность людей, которые стоят у его истоков.
При росте количества активных пользователей и их сессий, наличие балансировки и шардирования позитивно скажется на скорости обработки control plane. Время выхода UE в состояние RM-REGISTERED, время получения мобилой PDU Session Establishment Accept - это важные метрики, которые надо стремиться улучшать.
В user plane домене я понимаю хуже, так что поправляйте, если что. UPF selection - это control plane процедура. Если большое количество UE заходят через один gNB - это не значит, что кора должна посадить их на один UPF. Теперь, если UE распределились по нескольким UPF, значит dst IP и dst port - разные, следовательно и RSS hash разный. Таким образом UP пойдет на разные ядра.
Перечисленные балансировки и POSIX network stack разумно будет использовать для control plane (UE registration, PDU session establishment, etc.) Для user plane в Seastar есть диспачинг пакетов с использованием RSS, т.е. можно взять Seastar native stack over DPDK и поехали.
Вы по большому счету правы, однако было бы странно сразу перейти к нахваливанию Seastar за его killer фичи без краткого (о чем свидетельствует название статьи) сравнения с другими фреймворками, вследствие чего становится понятно, почему это именно killer фичи, а также позволяет избежать вопросов: «а что по поводу Boost.Asio», «а почему не попробовали userver» и т. п.
Более того содержимое статьи никак не противоречит вашему комментарию «Ну так и рассказывали бы больше о плюшках Seastar, не отвлекаясь на то, что вам не подошло». В статье так и есть - лишь краткое сравнение и обоснование, почему другие не подошли, а далее объемное (в рамках обзорной статьи) описание Seastar.
Спасибо за ваш комментарий, я учту его в будущих статьях :)
Если вопрос относительно POSIX stack, то seastar сильно много сверху не добавляет, а фактически передает управление в Linux.
Если речь про native stack, то можно посмотреть с двух сторон: 1) волков бояться — в лес не ходить :) хорошо что open-source, можно будет баг завести, либо самим починить 2) native stack можно просто не использовать, заменив чем-то другим.
Однако при выборе я бы не исходил из слишком уж больших опасений по поводу безопасности, потому что строго говоря, любая реализация может быть с багами, так что полагать, что у seastar их больше, чем у других - опрометчиво.
Уверенности придают кейсы использования этого фреймворка, а так же авторитетность людей, которые стоят у его истоков.
При росте количества активных пользователей и их сессий, наличие балансировки и шардирования позитивно скажется на скорости обработки control plane. Время выхода UE в состояние RM-REGISTERED, время получения мобилой PDU Session Establishment Accept - это важные метрики, которые надо стремиться улучшать.
В user plane домене я понимаю хуже, так что поправляйте, если что. UPF selection - это control plane процедура. Если большое количество UE заходят через один gNB - это не значит, что кора должна посадить их на один UPF. Теперь, если UE распределились по нескольким UPF, значит dst IP и dst port - разные, следовательно и RSS hash разный. Таким образом UP пойдет на разные ядра.
Перечисленные балансировки и POSIX network stack разумно будет использовать для control plane (UE registration, PDU session establishment, etc.) Для user plane в Seastar есть диспачинг пакетов с использованием RSS, т.е. можно взять Seastar native stack over DPDK и поехали.
Вы по большому счету правы, однако было бы странно сразу перейти к нахваливанию Seastar за его killer фичи без краткого (о чем свидетельствует название статьи) сравнения с другими фреймворками, вследствие чего становится понятно, почему это именно killer фичи, а также позволяет избежать вопросов: «а что по поводу Boost.Asio», «а почему не попробовали userver» и т. п.
Более того содержимое статьи никак не противоречит вашему комментарию «Ну так и рассказывали бы больше о плюшках Seastar, не отвлекаясь на то, что вам не подошло». В статье так и есть - лишь краткое сравнение и обоснование, почему другие не подошли, а далее объемное (в рамках обзорной статьи) описание Seastar.
Спасибо за ваш комментарий, я учту его в будущих статьях :)