Я не уверен, что в какой-либо организации одновременно работает multiqueue, packet steering, flow steering, qos и RAD. Увидеть такое в жизни будет офигенно (пропускная способность дикая будет), но я не верю в свободность бюрократии так хорошо работать.
Also, MSI-X, GRO и переход в polling mode после первого прерывания на некоторое время, и uring для приложения в финале. Или даже ebpf прямо в ядро.
А ещё power governor, управление pstates и boost'ом.
Все єто в любом супермаркете реализовано, и даже QoS - в виде єкспресс-касс. И да, єто не про бюрократию, а про бизнес в масс-сервисе, которій еще со времен Єрланга (которій человек) изучался. Собсно, стойла с барішнями на коммутаторах - чем не предшественник?
Это очень высокий уровень, который работает с приятненьким tcp, который эрлангу уже кто-то сделал готовенький.
Но есть кто-то, кто делает готовенький tcp, и там всё очень сложно: много ядер, локальный контекст, перенос которого между ядрами дорогой, и мы не хотим на каждый новый пакет переносить его. В то же самое время у нас есть куча ядер и мы не можем обрабатывать все пакеты на одном ядре. Это означает, что сетевая карта предоставляет несколько очередей, и каждое ядро обрабатывает свою очередь, но это создаёт проблему, в какую очередь какой пакет класть.
Ядру надо знать, какой сокет с какими 5-tuple (или другими признаками flow) соотносится и настраивать правила сетевой карты по определению очереди для принятия пакета.
Отдельная красота касается новых пакетов - их класть в round-robin, на least connections, на least load CPU (и связанную с ним очередь?)
Это очень глубокая область, сильно более глубокая, чем кассиры на кассах. По крайней мере я не видел кассовых сетапов на обработку 10 миллионов клиентов в секунду. Но было бы интересно посмотреть.
(Я так же не видел кода на эрланге, способного обрабатывать 10 миллионов flow в секунду на одной машине; не 10 миллионов обращений в секунду, а 10 миллионов активных соединений).
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
amarao
no subject
Date: 2024-09-11 02:35 pm (UTC)Also, MSI-X, GRO и переход в polling mode после первого прерывания на некоторое время, и uring для приложения в финале. Или даже ebpf прямо в ядро.
А ещё power governor, управление pstates и boost'ом.
no subject
Date: 2024-09-11 02:45 pm (UTC)И да, єто не про бюрократию, а про бизнес в масс-сервисе, которій еще со времен Єрланга (которій человек) изучался. Собсно, стойла с барішнями на коммутаторах - чем не предшественник?
no subject
Date: 2024-09-12 10:33 am (UTC)Но есть кто-то, кто делает готовенький tcp, и там всё очень сложно: много ядер, локальный контекст, перенос которого между ядрами дорогой, и мы не хотим на каждый новый пакет переносить его. В то же самое время у нас есть куча ядер и мы не можем обрабатывать все пакеты на одном ядре. Это означает, что сетевая карта предоставляет несколько очередей, и каждое ядро обрабатывает свою очередь, но это создаёт проблему, в какую очередь какой пакет класть.
Ядру надо знать, какой сокет с какими 5-tuple (или другими признаками flow) соотносится и настраивать правила сетевой карты по определению очереди для принятия пакета.
Отдельная красота касается новых пакетов - их класть в round-robin, на least connections, на least load CPU (и связанную с ним очередь?)
Это очень глубокая область, сильно более глубокая, чем кассиры на кассах. По крайней мере я не видел кассовых сетапов на обработку 10 миллионов клиентов в секунду. Но было бы интересно посмотреть.
(Я так же не видел кода на эрланге, способного обрабатывать 10 миллионов flow в секунду на одной машине; не 10 миллионов обращений в секунду, а 10 миллионов активных соединений).