Положить очередь стрима на определенное ядро.

Я не знаю, что за говно под словом «стримы» ты имеешь ввиду, но, глобально, распределить обработку пакетов по ядрам в linux помогает технология RPS. Гугл в помощь

я имею ввиду поток (stream) данных, приходящих на сокет. RPS - это ведь настройка NIC в целом, а мне надо распределить только для текущего приложения (причем мне это надо сделать изнутри).

Если обобщить - мне надо чтобы я мог регулировать в очередь какого ядра мне надо класть пакеты, полученного для данного сокета.

мне надо чтобы я мог регулировать в очередь какого ядра мне надо класть пакеты, полученного для данного сокета.

У ядра нет очередей пакетов. Я думаю, что ты хочешь невозможного (и ненужного).

А что за очереди тогда выводятся по 'ethtools -S'?

     Queue[0] InPackets: 1317147894
     Queue[0] OutPackets: 743795
     Queue[0] Restarts: 0
     Queue[0] InJumboPackets: 0
     Queue[0] InLroPackets: 0
     Queue[0] InErrors: 0
     Queue[1] InPackets: 1467899339
     Queue[1] OutPackets: 1262041
     Queue[1] Restarts: 0
     Queue[1] InJumboPackets: 0
     Queue[1] InLroPackets: 0
     Queue[1] InErrors: 0
     Queue[2] InPackets: 1270359724
     Queue[2] OutPackets: 2141474
     Queue[2] Restarts: 0
     Queue[2] InJumboPackets: 0
     Queue[2] InLroPackets: 0
     Queue[2] InErrors: 0
     Queue[3] InPackets: 693602894
     Queue[3] OutPackets: 920854
     Queue[3] Restarts: 0
     Queue[3] InJumboPackets: 0
     Queue[3] InLroPackets: 0
     Queue[3] InErrors: 0

Это надо смотреть в документации на карту или ее драйвер.

говорите про очередь которую якобы забираете с сокета а сами выхлоп внутренности сетевки показываете

Вот мне интересно - какой выигрыш приносит помещение разных потоков, работающих с одним ресурсом, на одно ядро? Планировщики в linux конечно хороши, но даже их работа чего то стоит и стоимость не есть число отрицательное, как мне мыслится.

думаешь, tailgunner знает о чём говорит?

этим очередям соответствуют ядерные потоки. их, конечно, можно принудительно разбросать по ядрам, но я считаю, что планировщик и по умолачнию справится с этой задачей не хуже тебя.

видимо, узкое место не здесь. как минимум, InErrors == 0.

Я могу ошибаться, но разве это не упомянутые выше RPS? Я как-то считал длинну бэклога и там как раз была структура per-CPU. Помню что per_cpu в enqueue_backlog был сделан как макрос и не получалось из ebpf его дергать для перехвата cpu с номером ядра для последующего вытягивания длинны списка.

Я могу ошибаться, но разве это не упомянутые выше RPS?

Насколько я знаю, RPS - это параллельная обработка прерываний от одной карты на разных процессорах. Никогда не слышал, чтобы он предоставлял юзерспейсу назначить сокету свой процессор.

AFAIK, вручную назначить сокет на процессор невозможно. На то, что нужно ТС, больше похоже RFS, но это опять же автоматический механизм, который вручную не настраивается. Хотя фразу «он может положить 3 или 4 очереди на одно ядро» я просто не понимаю.

SO_INCOMING_CPU

SO_INCOMING_CPU

Хм, есть возможность работать мимо RFS. Да, был неправ, признаю. Похоже, всё же есть способ сделать то, что хочет ТС.