Re: NIC interrupts / IRQs / Cores

Volodymyr Litovka

6 May 2025 6 May '25

11:18 a.m.

On 5/6/25 12:46, Andrey Blochintsev wrote:

Ось є документація - https://docs.kernel.org/networking/scaling.html - в якій є розділ RSS IRQ Configuration, де кажуть шо або irqbalance, або manual adjust відповідно до https://docs.kernel.org/core-api/irq/irq-affinity.html

...
Ок, для тесту я пішов в manul adjust й зробив відповідні smp_affinity (застопав irqbalance, звісно) - тут апаратні черги NIC чіпляються до різних IRQ, відповідно маска встановлена так, щоб розкидати це IRQ по 8 корам:

53 :: 00000000,00000000,0000ff00 :: 8-15 54 :: 00000000,00000000,00ff0000 :: 16-23 55 :: 00000000,00000000,ff000000 :: 24-31 56 :: 00000000,000000ff,00000000 :: 32-39 57 :: 00000000,0000ff00,00000000 :: 40-47 58 :: 00000000,00ff0000,00000000 :: 48-55 59 :: 00000000,ff000000,00000000 :: 56-63 60 :: 000000ff,00000000,00000000 :: 64-71

але дивлюсь на значення лічильників в /proc/interrupts й бачу що пох - шо з irqbalance, шо з маска в smp_affinity - приростає по кожному IRQ тільки на одній корі. Трафіку в цілому до біса (200к+ pps) - гадаю розкидає є шо.

А что в /proc/irq/{5[3-9],60}/{effective_affinity,effective_affinity,effective_affinity_list} ?

Гм.... такі не спрацювало - # for n in $(grep eno1 /proc/interrupts |awk '{print $1}' | tr -d ":"); do echo "$n :: $(cat /proc/irq/$n/smp_affinity) :: $(cat /proc/irq/$n/smp_affinity_list)"; done [ ... ] 93 :: 00000000,00000000,000000ff :: 0-7 # cat /proc/irq/93/{effective_affinity,effective_affinity,effective_affinity_list} 00000000,00000000,00000080 00000000,00000000,00000080 7 доки я буду курити ту доку, є ідеї - чому? дякую

...

https://www.kernel.org/doc/html/v6.13/core-api/genericirq.html

|effective_affinity|

The effective IRQ affinity on SMP as some irq chips do not allow multi CPU destinations. A subset of *affinity*.

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

Attachments:

attachment.html (text/html — 4.2 KB)
OpenPGP_0x25A0E7AE3791A60E.asc (application/pgp-keys — 3.1 KB)
OpenPGP_signature.asc (application/pgp-signature — 840 bytes)

Show replies by date

Volodymyr Litovka

6 May 6 May

3:56 p.m.

New subject: NIC interrupts / IRQs / Cores

Саме для interrupts мережевої карти не можна виставити декілька процесорів для обробки. Чи це характеристика мережевої карти чи ядра - ХЗ Але трішки обійти цю ситуацію вдалось збільшенням кількості черг: "ethtool -L eno1p0 combined 24" створила 24 черги, які кожна сіла на свій interrupt на свій процесор. On 5/6/25 13:18, Volodymyr Litovka wrote:

...

On 5/6/25 12:46, Andrey Blochintsev wrote:

...
Ось є документація - https://docs.kernel.org/networking/scaling.html - в якій є розділ RSS IRQ Configuration, де кажуть шо або irqbalance, або manual adjust відповідно до https://docs.kernel.org/core-api/irq/irq-affinity.html

...
Ок, для тесту я пішов в manul adjust й зробив відповідні smp_affinity (застопав irqbalance, звісно) - тут апаратні черги NIC чіпляються до різних IRQ, відповідно маска встановлена так, щоб розкидати це IRQ по 8 корам:

53 :: 00000000,00000000,0000ff00 :: 8-15 54 :: 00000000,00000000,00ff0000 :: 16-23 55 :: 00000000,00000000,ff000000 :: 24-31 56 :: 00000000,000000ff,00000000 :: 32-39 57 :: 00000000,0000ff00,00000000 :: 40-47 58 :: 00000000,00ff0000,00000000 :: 48-55 59 :: 00000000,ff000000,00000000 :: 56-63 60 :: 000000ff,00000000,00000000 :: 64-71

але дивлюсь на значення лічильників в /proc/interrupts й бачу що пох - шо з irqbalance, шо з маска в smp_affinity - приростає по кожному IRQ тільки на одній корі. Трафіку в цілому до біса (200к+ pps) - гадаю розкидає є шо.

А что в /proc/irq/{5[3-9],60}/{effective_affinity,effective_affinity,effective_affinity_list} ?

Гм.... такі не спрацювало -

# for n in $(grep eno1 /proc/interrupts |awk '{print $1}' | tr -d ":"); do echo "$n :: $(cat /proc/irq/$n/smp_affinity) :: $(cat /proc/irq/$n/smp_affinity_list)"; done [ ... ] 93 :: 00000000,00000000,000000ff :: 0-7

# cat /proc/irq/93/{effective_affinity,effective_affinity,effective_affinity_list} 00000000,00000000,00000080 00000000,00000000,00000080 7

доки я буду курити ту доку, є ідеї - чому?

дякую

...
https://www.kernel.org/doc/html/v6.13/core-api/genericirq.html

|effective_affinity|

The effective IRQ affinity on SMP as some irq chips do not allow multi CPU destinations. A subset of *affinity*.

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

Alexander V Soroka

7 May 7 May

1:06 p.m.

New subject: NIC interrupts / IRQs / Cores

Привет ! Ну вы странные люди :-) Вообще-то это аксиома, что "для interrupts мережевої карти не можна виставити декілька процесорів для обробки". Это вообще-то "АРХИТЕКТУРА железа" - в нее надо смотреть, но там по-любому если на карте один процессор и одна шина - то странно от нее хотеть многозадачности :-) Многозадачность ядер "Главного процессора" (вашего с Линуксом) должна подозревать многозадачность железа самой карты и "многопоточность" (а не имитацию) по связи - линиям между картой и Главным Процессором. У вас такие вопросы возникают потому, что вы "не от железа" шли к Программированию.А современное ООП и "процедурное с классами" полностью убили ПОНИМАНИЕ "как оно на самом деле внизу работает". Так что неудивительно... Зато таких как я "с железа вверх" программистов теперь никто на работу не возьмет, боя Jawa & Piton не знаю :-) и всякие "С-реакт" тоже... Tuesday, May 6, 2025, 6:56:03 PM, Volodymyr Litovka via UANOG uanog@uanog.one you wrote: VLvU> Саме для interrupts мережевої карти не можна виставити декілька VLvU> процесорів для обробки. Чи це характеристика мережевої карти чи ядра - ХЗ VLvU> Але трішки обійти цю ситуацію вдалось збільшенням кількості VLvU> черг: "ethtool -L eno1p0 combined 24" створила 24 черги, які VLvU> кожна сіла на свій interrupt на свій процесор. VLvU> On 5/6/25 13:18, Volodymyr Litovka wrote:

...

...
On 5/6/25 12:46, Andrey Blochintsev wrote:

...
Ось є документація - https://docs.kernel.org/networking/scaling.html >> - в якій є розділ RSS IRQ Configuration, де кажуть шо або irqbalance, >> або manual adjust відповідно до >> https://docs.kernel.org/core-api/irq/irq-affinity.html

...
Ок, для тесту я пішов в manul adjust й зробив відповідні >>> smp_affinity (застопав irqbalance, звісно) - тут апаратні черги NIC >>> чіпляються до різних IRQ, відповідно маска встановлена так, щоб >>> розкидати це IRQ по 8 корам:

53 :: 00000000,00000000,0000ff00 :: 8-15 54 :: 00000000,00000000,00ff0000 :: 16-23 55 :: 00000000,00000000,ff000000 :: 24-31 56 :: 00000000,000000ff,00000000 :: 32-39 57 :: 00000000,0000ff00,00000000 :: 40-47 58 :: 00000000,00ff0000,00000000 :: 48-55 59 :: 00000000,ff000000,00000000 :: 56-63 60 :: 000000ff,00000000,00000000 :: 64-71

але дивлюсь на значення лічильників в /proc/interrupts й бачу що пох >>> - шо з irqbalance, шо з маска в smp_affinity - приростає по кожному >>> IRQ тільки на одній корі. Трафіку в цілому до біса (200к+ pps) - >>> гадаю розкидає є шо.

А что в >> /proc/irq/{5[3-9],60}/{effective_affinity,effective_affinity,effective_affinity_list} >> ?

Гм.... такі не спрацювало -

# for n in $(grep eno1 /proc/interrupts |awk '{print $1}' | tr -d > ":"); do echo "$n :: $(cat /proc/irq/$n/smp_affinity) :: $(cat > /proc/irq/$n/smp_affinity_list)"; done [ ... ] 93 :: 00000000,00000000,000000ff :: 0-7

# cat > /proc/irq/93/{effective_affinity,effective_affinity,effective_affinity_list} 00000000,00000000,00000080 00000000,00000000,00000080 7

доки я буду курити ту доку, є ідеї - чому?

дякую

...
https://www.kernel.org/doc/html/v6.13/core-api/genericirq.html

|effective_affinity|

The effective IRQ affinity on SMP as some irq chips do not allow multi CPU destinations. A subset of *affinity*.

-- > Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

-- Best regards, Alexander V Soroka http://www.svr.ua/ AS106-RIPE mailto:alex@euro.net.ua

Volodymyr Litovka

3:58 p.m.

New subject: NIC interrupts / IRQs / Cores

Саша, ось для цього й існують розсилки та форуми - щоб питати те, чого не знаєш або не розумієш й отримувати відповіді й допомогу, а не лекції про те, які всі кругом лохи крім Дартан'яна :) Я щось не пам'ятаю, щоб на твої питання щодо домашніх раутерів хоч хтось сказав хоч щось подібне тому, що пишеш ти у своїх відповідях. On 5/7/25 15:06, Alexander V Soroka wrote:

...

Привет !

Ну вы странные люди :-) Вообще-то это аксиома, что "для interrupts мережевої карти не можна виставити декілька процесорів для обробки". Это вообще-то "АРХИТЕКТУРА железа" - в нее надо смотреть, но там по-любому если на карте один процессор и одна шина - то странно от нее хотеть многозадачности :-) Многозадачность ядер "Главного процессора" (вашего с Линуксом) должна подозревать многозадачность железа самой карты и "многопоточность" (а не имитацию) по связи - линиям между картой и Главным Процессором.

У вас такие вопросы возникают потому, что вы "не от железа" шли к Программированию.А современное ООП и "процедурное с классами" полностью убили ПОНИМАНИЕ "как оно на самом деле внизу работает". Так что неудивительно...

Зато таких как я "с железа вверх" программистов теперь никто на работу не возьмет, боя Jawa & Piton не знаю :-) и всякие "С-реакт" тоже...

Tuesday, May 6, 2025, 6:56:03 PM, Volodymyr Litovka via UANOG uanog@uanog.one you wrote: VLvU> Саме для interrupts мережевої карти не можна виставити декілька VLvU> процесорів для обробки. Чи це характеристика мережевої карти чи ядра - ХЗ

VLvU> Але трішки обійти цю ситуацію вдалось збільшенням кількості VLvU> черг: "ethtool -L eno1p0 combined 24" створила 24 черги, які VLvU> кожна сіла на свій interrupt на свій процесор.

VLvU> On 5/6/25 13:18, Volodymyr Litovka wrote:

...
...
On 5/6/25 12:46, Andrey Blochintsev wrote:

...
Ось є документація - https://docs.kernel.org/networking/scaling.html >> - в якій є розділ RSS IRQ Configuration, де кажуть шо або irqbalance, >> або manual adjust відповідно до >> https://docs.kernel.org/core-api/irq/irq-affinity.html

...
Ок, для тесту я пішов в manul adjust й зробив відповідні >>> smp_affinity (застопав irqbalance, звісно) - тут апаратні черги NIC >>> чіпляються до різних IRQ, відповідно маска встановлена так, щоб >>> розкидати це IRQ по 8 корам:

53 :: 00000000,00000000,0000ff00 :: 8-15 54 :: 00000000,00000000,00ff0000 :: 16-23 55 :: 00000000,00000000,ff000000 :: 24-31 56 :: 00000000,000000ff,00000000 :: 32-39 57 :: 00000000,0000ff00,00000000 :: 40-47 58 :: 00000000,00ff0000,00000000 :: 48-55 59 :: 00000000,ff000000,00000000 :: 56-63 60 :: 000000ff,00000000,00000000 :: 64-71

але дивлюсь на значення лічильників в /proc/interrupts й бачу що пох >>> - шо з irqbalance, шо з маска в smp_affinity - приростає по кожному >>> IRQ тільки на одній корі. Трафіку в цілому до біса (200к+ pps) - >>> гадаю розкидає є шо.

А что в >> /proc/irq/{5[3-9],60}/{effective_affinity,effective_affinity,effective_affinity_list} >> ? Гм.... такі не спрацювало -

# for n in $(grep eno1 /proc/interrupts |awk '{print $1}' | tr -d > ":"); do echo "$n :: $(cat /proc/irq/$n/smp_affinity) :: $(cat > /proc/irq/$n/smp_affinity_list)"; done [ ... ] 93 :: 00000000,00000000,000000ff :: 0-7

# cat > /proc/irq/93/{effective_affinity,effective_affinity,effective_affinity_list} 00000000,00000000,00000080 00000000,00000000,00000080 7

доки я буду курити ту доку, є ідеї - чому?

дякую

...
https://www.kernel.org/doc/html/v6.13/core-api/genericirq.html

|effective_affinity|

The effective IRQ affinity on SMP as some irq chips do not allow multi CPU destinations. A subset of *affinity*.

-- > Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

Alexander V Soroka

4:45 p.m.

New subject: NIC interrupts / IRQs / Cores

Привет ! ну на твой вопрос я ответил - это первая половина моего письма :-) а потом обьяснил, откуда ваши вопросы растут. А так как я в депресняке почти перманентном сейчас, то сорри, если кого обидел. Если кратко: я считаю что ЕСЛИ специально в описаних чипов-карт не написано что оно имеет "параельную обработку", то мульти-ядерные процессоры (главные) не могут получать разные данные от одной такой карты ОДНОВРЕМЕННО.Т.е. "многозадачность" и "многопоточность" это явление виртуальное а не "железное". Потому сколько ядер не используй а "узкое горло" будет именно в "одной карте". Именно поэтому народ н аРаспбери пай делает "кластеры", т.е. куча карт и каждая работает со своим эзернетом который на ее плате. Это так, "для вашей информированности". Wednesday, May 7, 2025, 6:58:04 PM, Volodymyr Litovka via UANOG uanog@uanog.one you wrote: VLvU> Саша, ось для цього й існують розсилки та форуми - щоб питати VLvU> те, чого не знаєш або не розумієш й отримувати відповіді й VLvU> допомогу, а не лекції про те, які всі кругом лохи крім Дартан'яна :) VLvU> Я щось не пам'ятаю, щоб на твої питання щодо домашніх раутерів VLvU> хоч хтось сказав хоч щось подібне тому, що пишеш ти у своїх відповідях. VLvU> On 5/7/25 15:06, Alexander V Soroka wrote:

...

...
Привет !

Ну вы странные люди :-) Вообще-то это аксиома, что "для interrupts мережевої карти не можна виставити декілька процесорів для обробки". Это вообще-то "АРХИТЕКТУРА железа" - в нее надо смотреть, но там по-любому если на карте один процессор и одна шина - то странно от нее хотеть многозадачности :-) Многозадачность ядер "Главного процессора" (вашего с Линуксом) должна подозревать многозадачность железа самой карты и "многопоточность" (а не имитацию) по связи - линиям между картой и Главным Процессором.

У вас такие вопросы возникают потому, что вы "не от железа" шли к Программированию.А современное ООП и "процедурное с классами" полностью убили ПОНИМАНИЕ "как оно на самом деле внизу работает". Так что неудивительно...

Зато таких как я "с железа вверх" программистов теперь никто на работу не возьмет, боя Jawa & Piton не знаю :-) и всякие "С-реакт" тоже...

Tuesday, May 6, 2025, 6:56:03 PM, Volodymyr Litovka via UANOG uanog@uanog.one you wrote: VLvU> Саме для interrupts мережевої карти не можна виставити декілька VLvU> процесорів для обробки. Чи це характеристика мережевої карти чи ядра - ХЗ

VLvU> Але трішки обійти цю ситуацію вдалось збільшенням кількості VLvU> черг: "ethtool -L eno1p0 combined 24" створила 24 черги, які VLvU> кожна сіла на свій interrupt на свій процесор.

VLvU> On 5/6/25 13:18, Volodymyr Litovka wrote:

...
...
On 5/6/25 12:46, Andrey Blochintsev wrote:

...
Ось є документація - https://docs.kernel.org/networking/scaling.html >> - в якій є розділ RSS IRQ Configuration, де кажуть шо або irqbalance, >> або manual adjust відповідно до >> https://docs.kernel.org/core-api/irq/irq-affinity.html

...
Ок, для тесту я пішов в manul adjust й зробив відповідні >>> smp_affinity (застопав irqbalance, звісно) - тут апаратні черги NIC >>> чіпляються до різних IRQ, відповідно маска встановлена так, щоб >>> розкидати це IRQ по 8 корам:

53 :: 00000000,00000000,0000ff00 :: 8-15 54 :: 00000000,00000000,00ff0000 :: 16-23 55 :: 00000000,00000000,ff000000 :: 24-31 56 :: 00000000,000000ff,00000000 :: 32-39 57 :: 00000000,0000ff00,00000000 :: 40-47 58 :: 00000000,00ff0000,00000000 :: 48-55 59 :: 00000000,ff000000,00000000 :: 56-63 60 :: 000000ff,00000000,00000000 :: 64-71

але дивлюсь на значення лічильників в /proc/interrupts й бачу що пох >>> - шо з irqbalance, шо з маска в smp_affinity - приростає по кожному >>> IRQ тільки на одній корі. Трафіку в цілому до біса (200к+ pps) - >>> гадаю розкидає є шо.

А что в >> /proc/irq/{5[3-9],60}/{effective_affinity,effective_affinity,effective_affinity_list} >> ? Гм.... такі не спрацювало -

# for n in $(grep eno1 /proc/interrupts |awk '{print $1}' | tr -d > ":"); do echo "$n :: $(cat /proc/irq/$n/smp_affinity) :: $(cat > /proc/irq/$n/smp_affinity_list)"; done [ ... ] 93 :: 00000000,00000000,000000ff :: 0-7

# cat > /proc/irq/93/{effective_affinity,effective_affinity,effective_affinity_list} 00000000,00000000,00000080 00000000,00000000,00000080 7

доки я буду курити ту доку, є ідеї - чому?

дякую

...
https://www.kernel.org/doc/html/v6.13/core-api/genericirq.html

|effective_affinity|

The effective IRQ affinity on SMP as some irq chips do not allow multi CPU destinations. A subset of *affinity*.

-- > Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

-- Best regards, Alexander V Soroka http://www.svr.ua/ AS106-RIPE mailto:alex@euro.net.ua

Alexander V Soroka

8 May 8 May

1:11 p.m.

New subject: NIC interrupts / IRQs / Cores

Привет ! у кого есть "час та натхнення" я рекомендую почитать книжку: https://kr-labs.com.ua/books/Tenenbaum_SoveremennyeOS.pdf чисто "Для общего развития". с 380 страницы - как раз про железо и обмены. и я особенно рекомендую с 393 страницы - "Точные и неточные прерывания". Очень хорошо описана проблематика простыми словами. Реально вы должны помнить: в современных компиляторах, вы программу пишете НЕ для железа а для "сферического процессора в акууме". Т.е. "программный код" не рассчитан на то что вот сейчас я его запущу именно с вот этогго адреса внутри памяти процессора :-) (я сейчас ОЧЕНЬ упрощаю...) Поэтому и наблюдается сейчас огромный отрыв в Программистах Старой Школы и тех кто начал писать уже с ООП и "джав". Старой школы уже отходят и умирают, а новой школы не появляется :-( Так вот, в мультипроцессорной системе, "железо" получается работает ТООЛЬКО через некую прокладку - т.е. ОС или "типа прокладок-драйверов", и вы, как Программист, постоянно оказываетесь в дурацкой ситуации: вы вроде как вынуждены применять некие функции (вызов функции) с передачей параметров, но в то же время вы полностью оторваны от "железных=аппаратных прерываний". ОС вам подсовывает некий "эрзац" который не всегда понятно как отрабатывать... (я сейчас ОЧЕНЬ упрощаю очень сложные процессы...) Все еще усугубляется современным "модным течением" по "низкоуровнему программингу на Питоне". Поубивал-бы... :-( это приводит к тому, что Программисты вообще не понимают "как оно там внутри на низком уровне". Это печально, и это уже привело к "программированию для сферического коня в вакууме". Но всем нравится и пипл хавает, создавая на всем этом прикладухи, а потом искренее удивляется, что оно глючит и хер знает как работает. Как выход предлагается все больше памяти и все больше тактовой частоты... но это путь в пропасть и коллапс. Спасибо за ваше внимание, я закончил. Я бы хотел чтобы это мое сообщение осталось тут "в архивах" :-) Прочтите Книгу по моей ссылке пожалуйста. Wednesday, May 7, 2025, 7:45:26 PM, Alexander V Soroka alex@euro.net.ua you wrote: AVS> Привет ! AVS> ну на твой вопрос я ответил - это первая половина моего письма :-) AVS> а потом обьяснил, откуда ваши вопросы растут. AVS> А так как я в депресняке почти перманентном сейчас, то сорри, если AVS> кого обидел. AVS> Если кратко: я считаю что ЕСЛИ специально в описаних чипов-карт не AVS> написано что оно имеет "параельную обработку", то мульти-ядерные AVS> процессоры (главные) не могут получать разные данные от одной такой AVS> карты ОДНОВРЕМЕННО.Т.е. "многозадачность" и "многопоточность" это AVS> явление виртуальное а не "железное". AVS> Потому сколько ядер не используй а "узкое горло" будет именно в "одной AVS> карте". AVS> Именно поэтому народ н аРаспбери пай делает "кластеры", т.е. куча карт AVS> и каждая работает со своим эзернетом который на ее плате. AVS> Это так, "для вашей информированности". AVS> Wednesday, May 7, 2025, 6:58:04 PM, Volodymyr Litovka via UANOG uanog@uanog.one you wrote: VLvU>> Саша, ось для цього й існують розсилки та форуми - щоб питати VLvU>> те, чого не знаєш або не розумієш й отримувати відповіді й VLvU>> допомогу, а не лекції про те, які всі кругом лохи крім Дартан'яна :) VLvU>> Я щось не пам'ятаю, щоб на твої питання щодо домашніх раутерів VLvU>> хоч хтось сказав хоч щось подібне тому, що пишеш ти у своїх відповідях. VLvU>> On 5/7/25 15:06, Alexander V Soroka wrote:

...

...
...
Привет !

Ну вы странные люди :-) Вообще-то это аксиома, что "для interrupts мережевої карти не можна виставити декілька процесорів для обробки". Это вообще-то "АРХИТЕКТУРА железа" - в нее надо смотреть, но там по-любому если на карте один процессор и одна шина - то странно от нее хотеть многозадачности :-) Многозадачность ядер "Главного процессора" (вашего с Линуксом) должна подозревать многозадачность железа самой карты и "многопоточность" (а не имитацию) по связи - линиям между картой и Главным Процессором.

У вас такие вопросы возникают потому, что вы "не от железа" шли к Программированию.А современное ООП и "процедурное с классами" полностью убили ПОНИМАНИЕ "как оно на самом деле внизу работает". Так что неудивительно...

Зато таких как я "с железа вверх" программистов теперь никто на работу не возьмет, боя Jawa & Piton не знаю :-) и всякие "С-реакт" тоже...

Tuesday, May 6, 2025, 6:56:03 PM, Volodymyr Litovka via UANOG uanog@uanog.one you wrote: VLvU> Саме для interrupts мережевої карти не можна виставити декілька VLvU> процесорів для обробки. Чи це характеристика мережевої карти чи ядра - ХЗ

VLvU> Але трішки обійти цю ситуацію вдалось збільшенням кількості VLvU> черг: "ethtool -L eno1p0 combined 24" створила 24 черги, які VLvU> кожна сіла на свій interrupt на свій процесор.

VLvU> On 5/6/25 13:18, Volodymyr Litovka wrote:

...
...
On 5/6/25 12:46, Andrey Blochintsev wrote:

...
Ось є документація - https://docs.kernel.org/networking/scaling.html >> - в якій є розділ RSS IRQ Configuration, де кажуть шо або irqbalance, >> або manual adjust відповідно до >> https://docs.kernel.org/core-api/irq/irq-affinity.html > Ок, для тесту я пішов в manul adjust й зробив відповідні >>> smp_affinity (застопав irqbalance, звісно) - тут апаратні черги NIC >>> чіпляються до різних IRQ, відповідно маска встановлена так, щоб >>> розкидати це IRQ по 8 корам: > > 53 :: 00000000,00000000,0000ff00 :: 8-15 > 54 :: 00000000,00000000,00ff0000 :: 16-23 > 55 :: 00000000,00000000,ff000000 :: 24-31 > 56 :: 00000000,000000ff,00000000 :: 32-39 > 57 :: 00000000,0000ff00,00000000 :: 40-47 > 58 :: 00000000,00ff0000,00000000 :: 48-55 > 59 :: 00000000,ff000000,00000000 :: 56-63 > 60 :: 000000ff,00000000,00000000 :: 64-71 > > але дивлюсь на значення лічильників в /proc/interrupts й бачу що пох >>> - шо з irqbalance, шо з маска в smp_affinity - приростає по кожному >>> IRQ тільки на одній корі. Трафіку в цілому до біса (200к+ pps) - >>> гадаю розкидає є шо. > >

А что в >> /proc/irq/{5[3-9],60}/{effective_affinity,effective_affinity,effective_affinity_list} >> ? Гм.... такі не спрацювало -

# for n in $(grep eno1 /proc/interrupts |awk '{print $1}' | tr -d > ":"); do echo "$n :: $(cat /proc/irq/$n/smp_affinity) :: $(cat > /proc/irq/$n/smp_affinity_list)"; done [ ... ] 93 :: 00000000,00000000,000000ff :: 0-7

# cat > /proc/irq/93/{effective_affinity,effective_affinity,effective_affinity_list} 00000000,00000000,00000080 00000000,00000000,00000080 7

доки я буду курити ту доку, є ідеї - чому?

дякую

...
https://www.kernel.org/doc/html/v6.13/core-api/genericirq.html

|effective_affinity|

The effective IRQ affinity on SMP as some irq chips do not allow multi CPU destinations. A subset of *affinity*.

-- > Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

-- Best regards, Alexander V Soroka http://www.svr.ua/ AS106-RIPE mailto:alex@euro.net.ua

Valentin Nechayev

2:35 p.m.

New subject: NIC interrupts / IRQs / Cores

hi, Thu, May 08, 2025 at 16:11:35, alex wrote about "[uanog] Re: NIC interrupts / IRQs / Cores":

...

с 380 страницы - как раз про железо и обмены. и я особенно рекомендую с 393 страницы - "Точные и неточные прерывания". Очень хорошо описана проблематика простыми словами.

Описана, да. Но: 1) Неточные прерывания (imprecise interrupts/exceptions/etc.) в современных архитектурах не присутствуют. Ну, может, в самых маргинальных осталось. Аппаратные - вообще я не слышал, чтобы такое хоть где-то было, потому что это недопустимо, чтобы в непредсказуемые моменты тебе невосстановимо ломало всю работу. Было в некоторых (например, SPARC до какого-то момента) для _исключений_, вызванных программными событиями, типа неподдерживаемой команды, и то не всех (page fault, например, туда не входил). Начиная с середины 1990-х, точные прерывания у всех даже при самом сложном out-of-order. Да, цена за это - задержка между приходом запроса на прерывание и фактическим переходом к обработчику (может быть, условно, десятки тактов), часть команд завершаются, часть отбрасывается, граница между выполненными и отброшенными зависит от массы факторов и может меняться с каждой новой моделью. И вот это (с той же страницы)

...

поскольку после попытки деления на нуль перезапускать работавший процесс не имеет смысла.

Таненбаум неправ, оно может иметь смысл при самых разных ситуациях, юниксы генерируют сигнал, который может быть перехвачен, Windows через SEH позволяет ловить такие ситуации, в других ОС свои механизмы, но все позволяют адекватно перехватывать такое без фатальных последствий для процесса. Судя по тому, что в POWER точные исключения завезли в 1990, в x86 с момента его перехода в OoO (PentiumPro - 1996), а в S/370 ещё в 70-х - он отстал уже к моменту написания книги. 2) А какое это вообще имеет отношение к вопросу распределения прерываний по хартам/ядрам/процессорам/назови_как_хочешь? Там вопрос в том, чтобы сетевуха в принципе позволяла настраивать генерацию разных прерываний на разные ситуации, а дальше их раутинга по сети обработки, но сама обработка прерывания не меняется. Или вы про то, что вообще тема сложная?

...

Реально вы должны помнить: в современных компиляторах, вы программу пишете НЕ для железа а для "сферического процессора в акууме". Т.е. "программный код" не рассчитан на то что вот сейчас я его запущу именно с вот этогго адреса внутри памяти процессора :-) (я сейчас ОЧЕНЬ упрощаю...) Поэтому и наблюдается сейчас огромный отрыв в Программистах Старой Школы и тех кто начал писать уже с ООП и "джав". Старой школы уже отходят и умирают, а новой школы не появляется :-(

Так тем, кто пишет на верхних уровнях, это всё обычно и не нужно. Зато они другое умеют. Я вот например веб знаю на уровне HTML3.2 без CSS. А они знают и могут за час наклепать морду управления какой-то железякой с неплохим UI, им только надо сказать, за какие рычаги дёргать на стороне сервера - а я бы это неделю писал. Каждому тут своё.

...

Так вот, в мультипроцессорной системе, "железо" получается работает ТООЛЬКО через некую прокладку - т.е. ОС или "типа прокладок-драйверов", и вы, как Программист, постоянно оказываетесь в дурацкой ситуации: вы вроде как вынуждены применять некие функции (вызов функции) с передачей параметров, но в то же время вы полностью оторваны от "железных=аппаратных прерываний". ОС вам подсовывает некий "эрзац" который не всегда понятно как отрабатывать... (я сейчас ОЧЕНЬ упрощаю очень сложные процессы...)

А что, просто на уровне ОС это уже не был эрзац? Top half (hardinterrupt), bottom half (softinterrupt), состояние драйвера, wakeup в обработчике, sleep в process land, пока вышел, пока проверил, что нет сигналов процесса, пока шедулер разрешил исполняться...

...

Все еще усугубляется современным "модным течением" по "низкоуровнему программингу на Питоне". Поубивал-бы... :-( это приводит к тому, что Программисты вообще не понимают "как оно там внутри на низком уровне". Это печально, и это уже привело к "программированию для сферического коня в вакууме".

Что именно надо понимать, если задача выглядит в виде "при условии функция need_buka поставить высокий уровень на выходную ногу 12", когда эта need_buka видит, например, команду оператора "дави его!", а от того питона там клей между serial и gpio? (чисто условно) Разве что то, что это будет отрабатывать, условно, 20мс вместо 100мкс, но если это проблема, будет отдельное ТЗ.

...

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

Спасибо за ваше внимание, я закончил. Я бы хотел чтобы это мое сообщение осталось тут "в архивах" :-) Прочтите Книгу по моей ссылке пожалуйста.

Не могу говорить за всех, но я читал. Как первое описание очень даже неплохо, но надо учесть, сколько туда не попало, и что ей концептуально уже лет 20-30 и она не переписывалась... -netch-

Alexander V Soroka

9 May 9 May

7:12 a.m.

New subject: NIC interrupts / IRQs / Cores

Привет ! мои ответы ниже. Thursday, May 8, 2025, 5:35:22 PM, Valentin Nechayev netch@netch.kiev.ua you wrote: VN> Thu, May 08, 2025 at 16:11:35, alex wrote about "[uanog] Re: NIC interrupts / IRQs / Cores":

...

...
с 380 страницы - как раз про железо и обмены. и я особенно рекомендую с 393 страницы - "Точные и неточные прерывания". Очень хорошо описана проблематика простыми словами.

VN> Описана, да. Но: VN> 1) Неточные прерывания (imprecise interrupts/exceptions/etc.) в VN> современных архитектурах не присутствуют. Ну, может, в самых VN> маргинальных осталось. Тут надо понимать, что в книге точно описаны прерывания "как это работает". И с 90х ничего не поменялось в этом плане. Прерывания трех видов: 1) аппаратное, когда "все стоп! сохраняем все регистры в стеке и прыгаем на прогу обработки прерывания". 2) аппартное, мы выставляем "флаг" в каком-то регистре и идем дальше, если никто не пришел за данными, то они перезаписываются следующими. 3) аппаратное, Учтройство приняло кусок данных, и само инициировало по Прямому Доступу к Памяти (ПДП) перенос данных в некую область Памяти. После этого Устройство продолжает работу. Т.е. Процессор сам по себе, Устройство само по себе, а данные блокируют доступ Процессора к Памяти только на момент "перелива".При этом если Процессор н е"ходит" в той области памяти куда льет Устройство по ПДП, то ничего не тормозится. Нечеткие прерывания это скорее к (2) т к (3) . А (1) ничего не поменялось. Если же мы говорим о "делении на ноль" то это может быть как аппартное прерывание так и программное, т.е. Операционка сама, какие-то кванты времени, "смотрит" в "лог событий" и там если видит эксепшн или некое "уведомление о событии" то запускает процесс который с этим что-то делает. Или не делает :-) Посмотрите в ВИнде сколько "ошибок страниц" там пролетает за минуту. И ниче - все живы :-) А вот теперь скажите мне: если у вас в Процессоре есть 16 ядер, то КАКОЙ ИЗ НИХ должно отвлекаться на прерывание? Вопрос еще усложняется когда у каждого Ядра есть свой Кеш "уровня Х", куда заранее подгружается кусок исполняемого кода? Тут такой хаос можно устройить... Я не хочу сильно углубляться в проблемы "железа и то как пишут Люди", но сейчас вот все это отдается на откуп Компилятору С, который уже сам решает все эти пролемы - т.е. кто что из Ядер должен делать, как настроить Обработчик прерываний и т.п. Вы на "верхнем уровне" писанины программ этого не видите вообще. Поэтому и получаются глюки - компилятор не имеет "мозга" а работает стандартными кусками кода (конфифгурации). И если вы специально не лезете в регистры управления Устройства(микросхем) то вы полностью зависите от Компилятора и того что курили индусы которые написали код этого компилятора :-) Я пишу для низкого уровня , микропроцессоры, и пишу на С99 так, чтобы в коде потом все было как мне нужно (асемблерный код). Полезно использовать https://godbolt.org/ для того чтобы понимать как вот этофсе вот что ты сейчас написал, будет вывернуто в ассемблер. И сколько "подвызовов процедур" реально "стоит" твоя вот эта команда с передачей параметров через стек. VN> Аппаратные - вообще я не слышал, чтобы такое хоть где-то было, потому VN> что это недопустимо, чтобы в непредсказуемые моменты тебе VN> невосстановимо ломало всю работу. Вы ошибаетесь. Ничего не ломается. Просто Процессор складывает в стек часть или все регистры и прыгает по адресу "Обработки прерывания". Тут ничего не изменилось с 90х годов, просто добавились всякие косвенные и т.п. адресации для удобства. Даташит на любой Процессор открываем и читаем. В случае одного Процессора, вы будете иметь "лаг-задержку" на время пока Процессор отработает код в прерывании, и вернется в точку откуда прыгал, загрузит спрятанные в стеке регистры, и продолжит работу с того же места. С вашей точки зрения вы даже не увидите что это все было - только "вдруг лаг" по тактам выполнения (строчкам выполнения). Если же у нас несколько ядер то каждое Ядро это отдельный Процессор. Там уже и своя память и Арбитр Прерываний - т.е. Программа (после компилятора) должна как-то указывать как будут распределяться обработки прерываний среди Ядер. Это про аппаратное я написал. Теперь про любимые "типа реал тайм системы" :-) Под этими RTOS сейчас для железа есть то что просто тупо по таймеру выдает "кванты ресурсов на обработку", и потом то же самое: прячер мегистры, указатели, и отдаем память Процессору и новому "треду" или новому куску кода.Это получается НАДстройка НАД аппартными прерываниями как от Устройств так и от Таймеров. Кому интересно - полистайте исходный код Адупайлота - основной проги БПЛА, которая управляет "типа реал тайм" всем самолетом. Там внутри своя операционка, с описанием сколько "таймслотов" надо выделит какой из подпрограмм. И что делать если прога зависла (через сколько милисек перезапуск подпрограммы). вот характерный кусочек: ... const AP_Scheduler::Task Plane::scheduler_tasks[] PROGMEM = { { SCHED_TASK(read_radio), 1, 700 }, // 0 { SCHED_TASK(check_short_failsafe), 1, 1000 }, { SCHED_TASK(ahrs_update), 1, 6400 }, { SCHED_TASK(update_speed_height), 1, 1600 }, { SCHED_TASK(update_flight_mode), 1, 1400 }, { SCHED_TASK(stabilize), 1, 3500 }, { SCHED_TASK(set_servos), 1, 1600 }, { SCHED_TASK(read_control_switch), 7, 1000 }, { SCHED_TASK(gcs_retry_deferred), 1, 1000 }, { SCHED_TASK(update_GPS_50Hz), 1, 2500 }, { SCHED_TASK(update_GPS_10Hz), 5, 2500 }, // 10 { SCHED_TASK(navigate), 5, 3000 }, { SCHED_TASK(update_compass), 5, 1200 }, { SCHED_TASK(read_airspeed), 5, 1200 }, { SCHED_TASK(update_alt), 5, 3400 }, { SCHED_TASK(adjust_altitude_target), 5, 1000 }, { SCHED_TASK(obc_fs_check), 5, 1000 }, { SCHED_TASK(gcs_update), 1, 1700 }, { SCHED_TASK(gcs_data_stream_send), 1, 3000 }, { SCHED_TASK(update_events), 1, 1500 }, // 20 { SCHED_TASK(check_usb_mux), 5, 300 }, { SCHED_TASK(read_battery), 5, 1000 }, { SCHED_TASK(compass_accumulate), 1, 1500 }, { SCHED_TASK(barometer_accumulate), 1, 900 }, { SCHED_TASK(update_notify), 1, 300 }, { SCHED_TASK(read_rangefinder), 1, 500 }, #if OPTFLOW == ENABLED { SCHED_TASK(update_optical_flow), 1, 500 }, #endif { SCHED_TASK(one_second_loop), 50, 1000 }, { SCHED_TASK(check_long_failsafe), 15, 1000 }, { SCHED_TASK(read_receiver_rssi), 5, 1000 }, { SCHED_TASK(airspeed_ratio_update), 50, 1000 }, // 30 { SCHED_TASK(update_mount), 1, 1500 }, { SCHED_TASK(log_perf_info), 500, 1000 }, { SCHED_TASK(compass_save), 3000, 2500 }, { SCHED_TASK(update_logging1), 5, 1700 }, { SCHED_TASK(update_logging2), 5, 1700 }, #if FRSKY_TELEM_ENABLED == ENABLED { SCHED_TASK(frsky_telemetry_send), 10, 100 }, #endif { SCHED_TASK(terrain_update), 5, 500 }, }; ... Все RTOS так устроены. И Линукс тоже, просто в нем нет такой жесткой слежки за "квантами вычислений". Я сейчас сильно упрощаю, чтобы мысль свою донести. VN> Было в некоторых (например, SPARC до VN> какого-то момента) для _исключений_, вызванных программными событиями, VN> типа неподдерживаемой команды, и то не всех (page fault, например, VN> туда не входил). Так вот в Винде, да и практически во всех ОС сейчас, вам отрезали все возмождности напрямую работать с жедезом. Вам оставили "виртуалки" которые работают через прокладку ОС и ее драйверов. Фактически все держится на очнеь высоком быстродействии... ... VN> Судя по тому, что в POWER точные исключения завезли в 1990, в x86 с VN> момента его перехода в OoO (PentiumPro - 1996), а в S/370 ещё в 70-х - VN> он отстал уже к моменту написания книги. ничего он не отстал. :-) VN> 2) А какое это вообще имеет отношение к вопросу распределения VN> прерываний по хартам/ядрам/процессорам/назови_как_хочешь? Там вопрос в VN> том, чтобы сетевуха в принципе позволяла настраивать генерацию разных VN> прерываний на разные ситуации, а дальше их раутинга по сети обработки, VN> но сама обработка прерывания не меняется. VN> Или вы про то, что вообще тема сложная? Вы не поняли. Я выше описал как это работает, в Книге тоже точно описано. Ничего не поменялось. Смотрим страницу 396. Тут ничего не поменялось с 90х. Цитата: "...Еще один важный вопрос — какой способ применить для передачи данных, синхронный (блокирующий) или асинхронный (управляемый с помощью прерываний). Большинство физических операций ввода-вывода осуществляется в асинхронном режиме: центральный процессор инициирует передачу данных и устраняется от нее для выполнения каких-нибудь других задач до тех пор, пока не поступит прерывание. А вот прикладные программы значительно легче писать, если операции ввода-вывода осуществляются в блокирующем режиме: после системного вызова read программа автоматически приостанавливается до тех пор, пока данные не поступят в буфер. На операционную систему возлагается задача, чтобы фактически управляемые с помощью прерываний операции выглядели для пользовательской программы как блокирующие. ..." Тут ничего не поменялось с тех пор. И ваша "сетевуха" может работать как я писал выше - в одном из трех режимов. Но сейчас все стараются делать (3) чтобы Устройство работало "в иной реальности времени" само по себе, а некий Арбитр должен управлять потоками данных. Иначе полная жопа будет... И число ядер тут как раз при чем - Устройство (Сеть) это ПОСЛЕДОВАТЕЛЬНЫЙ ОБМЕН. Т.е. пока летит в сетевом кабеле один пакет, второй никто не примет. Значит Устройство должно принимать все что "нормальное" куда-то в буфер, выставлять "флаги" а потом Ядра как-то(?) должны весь этот буфер разгребать. И если Ядра быстрые то они стоят, а Устройство тупо принимает пакеты и складывает. Можно в Устройство всунуть свой Процессор, очень быстрый, который будет устанавливать "еще один уровень" между Сетью(кабель) и Процессорными Ядрами (верхний уровень). Типа предварительной фильтрации по MAC "а это вообще мне?" . Вы поняли что я написал сейчас ?

...

...
Реально вы должны помнить: в современных компиляторах, вы программу пишете НЕ для железа а для "сферического процессора в акууме". Т.е. "программный код" не рассчитан на то что вот сейчас я его запущу именно с вот этогго адреса внутри памяти процессора :-) (я сейчас ОЧЕНЬ упрощаю...) Поэтому и наблюдается сейчас огромный отрыв в Программистах Старой Школы и тех кто начал писать уже с ООП и "джав". Старой школы уже отходят и умирают, а новой школы не появляется :-(

VN> Так тем, кто пишет на верхних уровнях, это всё обычно и не нужно. Зато VN> они другое умеют. Я вот например веб знаю на уровне HTML3.2 без CSS. А VN> они знают и могут за час наклепать морду управления какой-то железякой VN> с неплохим UI, им только надо сказать, за какие рычаги дёргать на VN> стороне сервера - а я бы это неделю писал. Каждому тут своё. Вы расплачиваетесь за нежелание "лезть ниже" тем что теряете производительность в 1000 раз примерно :-(. Яркие примеры сейчас - писанина для STM32 любимых контроллеров БПЛА на HAL библиотеках просто уничтожает все эти 70-150МГц таковой частоты :-( оно тупо еле вывозит такие программы. А еще сейчас куча проблем с ИИ, который "в библиотеках", которые неподьемные из-за такой вот наплевательской манеры написани кода вида "и так сойдет, если не хватает мощщи то поставьте проц пошустрее". :-( То эе самое сейчас с "переходом на цифру". Задержки на обработке видео с камеры и передаче этого в радиоканал. Я слежу за темами с 22 года - там "мрак и пьяные матросы", но все уверены что "вот-вот получится"... а ошибка то в генетике - в неправильном подходе к построению Системы. Но маладежжж только себя слушает.

...

...
Так вот, в мультипроцессорной системе, "железо" получается работает ТООЛЬКО через некую прокладку - т.е. ОС или "типа прокладок-драйверов", и вы, как Программист, постоянно оказываетесь в дурацкой ситуации: вы вроде как вынуждены применять некие функции (вызов функции) с передачей параметров, но в то же время вы полностью оторваны от "железных=аппаратных прерываний". ОС вам подсовывает некий "эрзац" который не всегда понятно как отрабатывать... (я сейчас ОЧЕНЬ упрощаю очень сложные процессы...)

VN> А что, просто на уровне ОС это уже не был эрзац? Top half VN> (hardinterrupt), bottom half (softinterrupt), состояние драйвера, VN> wakeup в обработчике, sleep в process land, пока вышел, пока проверил, VN> что нет сигналов процесса, пока шедулер разрешил исполняться...

...

...
Все еще усугубляется современным "модным течением" по "низкоуровнему программингу на Питоне". Поубивал-бы... :-( это приводит к тому, что Программисты вообще не понимают "как оно там внутри на низком уровне". Это печально, и это уже привело к "программированию для сферического коня в вакууме".

VN> Что именно надо понимать, если задача выглядит в виде "при условии VN> функция need_buka поставить высокий уровень на выходную ногу 12", VN> когда эта need_buka видит, например, команду оператора "дави его!", VN> а от того питона там клей между serial и gpio? VN> (чисто условно) VN> Разве что то, что это будет отрабатывать, условно, 20мс вместо VN> 100мкс, но если это проблема, будет отдельное ТЗ.

...

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

Спасибо за ваше внимание, я закончил. Я бы хотел чтобы это мое сообщение осталось тут "в архивах" :-) Прочтите Книгу по моей ссылке пожалуйста.

VN> Не могу говорить за всех, но я читал. Как первое описание очень даже VN> неплохо, но надо учесть, сколько туда не попало, и что ей VN> концептуально уже лет 20-30 и она не переписывалась... VN> -netch- -- Best regards, Alexander V Soroka http://www.svr.ua/ AS106-RIPE mailto:alex@euro.net.ua

Volodymyr Sharun

7:33 a.m.

New subject: NIC interrupts / IRQs / Cores

Александр Васильевич, Современная сетевая карта - это полноценный комп, это больше не 8237, саундбластер про и десяток их регистров/портов. Драйвера для нее настолько сложны, что нет смысла даже начинать, это сотни мегабайт кода фирмвари и мегабайты кода интерфейса со стороны ОС к этой фирмвари. Нет никакой необходимости что-то понимать или не понимать, нужен опыт тюнинга, пара обзоров и не более того, кто что пробовал. Это тот случай, когда проще поменять/поэкспериментировать и *не терять больше на этом времени. Время стоит очень дорого, намного дороже, чем железо.* Люди на жизнь зарабатывают тем, что умеют быстро что-то там подкрутить и оно едет дальше как-то удовлетворительно, глубокого понимания больше не нужно, оно *не поможет *с тюнингом*, достаточно спросить *у ChatGPT или на/у Stackoverflow через гугла. Поезд глубокого понимания программирования PIC/DMA ушел, оно нужно тем, кто программят PIC/APIC/DMA, а тем, кто настраивает, больше это не нужно. Мало того, когда мне недавно нужен был РоС, ЧатГПТ сделал мне C/Asm код за 5 минут, т.е. *тратить время *на написание кода - тоже не надо - это дорого. Организация, в которой я сейчас работаю, подавляющее большинство кода пишется в подписочном ChatGPT (от ошибок в дизайне софта впрочем не спасает). Мало того, я вот недавно был свидетелем горя от ума на этой почве, когда желание прикрутить именно 8237 в мосте ITE к современной платформе через мост PCIe-PCI-ISA и глубокое понимание как работает DMA в современных системах привело к тому, что человек потерялся в маршрутизации этих сигналов: сделал от карты к процу возврат, а от проца к карте - нет, ну типа как-то придумаем, когда ему все говорят астанавитесь, нет возможности субстрактивного декодинга 00-FF портов, они легаси и хардвайред в PCH, нет, я найду как. Ну ок. Способа нет, кроме VM или недокументированных трапов SMM. Чел остановился на VM варианте, с которым всё остальное (сделать всё только на железе) теряет смысл. On Fri, May 9, 2025 at 10:12 AM Alexander V Soroka wrote:

...

1) аппаратное, когда "все стоп! сохраняем все регистры в стеке и прыгаем на прогу обработки прерывания". 2) аппартное, мы выставляем "флаг" в каком-то регистре и идем дальше, если никто не пришел за данными, то они перезаписываются следующими. 3) аппаратное, Учтройство приняло кусок данных, и само инициировало по Прямому Доступу к Памяти (ПДП) перенос данных в некую область Памяти. После этого Устройство продолжает работу. Т.е. Процессор сам по себе, Устройство само по себе, а данные блокируют доступ Процессора к Памяти только на момент "перелива".При этом если Процессор н е"ходит" в той области памяти куда льет Устройство по ПДП, то ничего не тормозится.

Alexander V Soroka

7:55 a.m.

New subject: NIC interrupts / IRQs / Cores

Привет ! Согласен с тобой :-) это то что я писал - "комп" всунули в саму карту, и туда-же всунули "прогу-драйвер", и по системной шине тепреь с Процессорными Ядрами работает уже ОС и ПроцессорСетевойКарты. То же самое сейчас с Видеокартами - CUDA и прочее. Но - то что я пишу и что в Книге - это так и есть, просто НАДстройка появилась там, над Сетевым Кабелем и той микросхемой (внутри СпецПроцессора Карты) которая стоит в карте. Я о ПРИНЦИПАХ. Принципы не меняются, прогресс идет в сторону "не твое собачье дело как оно там внутри работает - воттебе API - пошел отсюда". Современная Связь - это сейчас "мирочип с Процессором и аппартной частью". Тема по дронам тому пример... LoRa это "микроконтроллер с радиопередатчиком внутри". Все ! :-) Теперь вам не нужно знать про Радио - вам нужно просто обьяснить Процессору Радио что вы там всовываете и на каком канале это выстрелить. Или принять. Прогресс понятно куда идет и пришел. Friday, May 9, 2025, 10:33:42 AM, Volodymyr Sharun vsharun@gmail.com you wrote: VS> Александр Васильевич, VS> Современная сетевая карта - это полноценный комп, это больше не 8237, VS> саундбластер про и десяток их регистров/портов. VS> Драйвера для нее настолько сложны, что нет смысла даже начинать, это сотни VS> мегабайт кода фирмвари и мегабайты кода интерфейса со стороны ОС к этой VS> фирмвари. VS> Нет никакой необходимости что-то понимать или не понимать, нужен опыт VS> тюнинга, пара обзоров и не более того, кто что пробовал. VS> Это тот случай, когда проще поменять/поэкспериментировать и *не терять VS> больше на этом времени. Время стоит очень дорого, намного дороже, чем VS> железо.* VS> Люди на жизнь зарабатывают тем, что умеют быстро что-то там подкрутить и VS> оно едет дальше как-то удовлетворительно, глубокого понимания больше не VS> нужно, оно *не поможет *с тюнингом*, достаточно спросить *у ChatGPT или VS> на/у Stackoverflow через гугла. VS> Поезд глубокого понимания программирования PIC/DMA ушел, оно нужно тем, кто VS> программят PIC/APIC/DMA, а тем, кто настраивает, больше это не нужно. Мало VS> того, когда мне недавно нужен был РоС, ЧатГПТ сделал мне C/Asm код за 5 VS> минут, т.е. *тратить время *на написание кода - тоже не надо - это дорого. VS> Организация, в которой я сейчас работаю, подавляющее большинство кода VS> пишется в подписочном ChatGPT (от ошибок в дизайне софта впрочем не VS> спасает). VS> Мало того, я вот недавно был свидетелем горя от ума на этой почве, когда VS> желание прикрутить именно 8237 в мосте ITE к современной платформе через VS> мост PCIe-PCI-ISA и глубокое понимание как работает DMA в современных VS> системах привело к тому, что человек потерялся в маршрутизации этих VS> сигналов: сделал от карты к процу возврат, а от проца к карте - нет, ну VS> типа как-то придумаем, когда ему все говорят астанавитесь, нет возможности VS> субстрактивного декодинга 00-FF портов, они легаси и хардвайред в PCH, нет, VS> я найду как. Ну ок. Способа нет, кроме VM или недокументированных трапов VS> SMM. Чел остановился на VM варианте, с которым всё остальное (сделать всё VS> только на железе) теряет смысл. VS> On Fri, May 9, 2025 at 10:12 AM Alexander V Soroka wrote:

...

...
1) аппаратное, когда "все стоп! сохраняем все регистры в стеке и прыгаем на прогу обработки прерывания". 2) аппартное, мы выставляем "флаг" в каком-то регистре и идем дальше, если никто не пришел за данными, то они перезаписываются следующими. 3) аппаратное, Учтройство приняло кусок данных, и само инициировало по Прямому Доступу к Памяти (ПДП) перенос данных в некую область Памяти. После этого Устройство продолжает работу. Т.е. Процессор сам по себе, Устройство само по себе, а данные блокируют доступ Процессора к Памяти только на момент "перелива".При этом если Процессор н е"ходит" в той области памяти куда льет Устройство по ПДП, то ничего не тормозится.

VS> _______________________________________________ VS> UANOG mailing list -- uanog@uanog.one VS> To unsubscribe send an email to uanog-leave@uanog.one -- Best regards, Alexander V Soroka http://www.svr.ua/ AS106-RIPE mailto:alex@euro.net.ua

Volodymyr Sharun

8:02 a.m.

New subject: NIC interrupts / IRQs / Cores

Привет, Возможность на коленке сделать PoC из коммодити и быстро внедрить/масштабировать из коммодити продукт с добавленной стоимостью, вместо годов разработки дискретного решения "по-старинке". Да, оно несет за собой какие-то моменты типа не до конца знаешь как оно там под капотом работает, но время сокращается на порядки. Время - это ресурс, который нельзя купить. Можно только процесс оптимизировать и "не проиграть". On Fri, May 9, 2025 at 10:55 AM Alexander V Soroka wrote:

...

Теперь вам не нужно знать про Радио - вам нужно просто обьяснить Процессору Радио что вы там всовываете и на каком канале это выстрелить. Или принять. Прогресс понятно куда идет и пришел.

Max Tulyev

12:03 p.m.

New subject: NIC interrupts / IRQs / Cores

Привет! Ну как же принципы не поменялись... Если раньше оно работало как "ПРЕРЫВАНИЕ: всем стоп! пакет из сети пришёл! Обрабатывать!" То сейчас оно работает так: "ОС: такс, у нас есть ядро номер 10. Почему номер 10? Да потому что оно сейчас посвободнее. Ага... Сетевуха, у нас тут 10-й простаивает! Эй, планировщик ядра 10, у тебя сетевуха в L2 кеш насрала 10 мегабайт, поставь следующим таском разгрести это!" Тут вообще прерываний в старом понимании нету. Как по мне, сильно огромная разница. И лезть ТУТ ниже тупо бессмысленно. Ну, если у тебя нет команды, которая перепишет ЭТО ВСЁ лучше, чем оно было уже написано. Да, вышесказанное не относится к любителям писать на питоне для STM32 и потом ныть а чо оно тормозит. Там как раз всё по-старинке, и реально надо понимать чо делаешь. On Fri, 9 May 2025 10:55:03 +0300 Alexander V Soroka wrote:

...

Привет !

Согласен с тобой :-) это то что я писал - "комп" всунули в саму карту, и туда-же всунули "прогу-драйвер", и по системной шине тепреь с Процессорными Ядрами работает уже ОС и ПроцессорСетевойКарты. То же самое сейчас с Видеокартами - CUDA и прочее.

Но - то что я пишу и что в Книге - это так и есть, просто НАДстройка появилась там, над Сетевым Кабелем и той микросхемой (внутри СпецПроцессора Карты) которая стоит в карте. Я о ПРИНЦИПАХ. Принципы не меняются, прогресс идет в сторону "не твое собачье дело как оно там внутри работает - воттебе API - пошел отсюда". Современная Связь - это сейчас "мирочип с Процессором и аппартной частью". Тема по дронам тому пример... LoRa это "микроконтроллер с радиопередатчиком внутри". Все ! :-) Теперь вам не нужно знать про Радио - вам нужно просто обьяснить Процессору Радио что вы там всовываете и на каком канале это выстрелить. Или принять. Прогресс понятно куда идет и пришел.

Friday, May 9, 2025, 10:33:42 AM, Volodymyr Sharun vsharun@gmail.com you wrote: VS> Александр Васильевич, VS> Современная сетевая карта - это полноценный комп, это больше не 8237, VS> саундбластер про и десяток их регистров/портов. VS> Драйвера для нее настолько сложны, что нет смысла даже начинать, это сотни VS> мегабайт кода фирмвари и мегабайты кода интерфейса со стороны ОС к этой VS> фирмвари. VS> Нет никакой необходимости что-то понимать или не понимать, нужен опыт VS> тюнинга, пара обзоров и не более того, кто что пробовал. VS> Это тот случай, когда проще поменять/поэкспериментировать и *не терять VS> больше на этом времени. Время стоит очень дорого, намного дороже, чем VS> железо.* VS> Люди на жизнь зарабатывают тем, что умеют быстро что-то там подкрутить и VS> оно едет дальше как-то удовлетворительно, глубокого понимания больше не VS> нужно, оно *не поможет *с тюнингом*, достаточно спросить *у ChatGPT или VS> на/у Stackoverflow через гугла.

VS> Поезд глубокого понимания программирования PIC/DMA ушел, оно нужно тем, кто VS> программят PIC/APIC/DMA, а тем, кто настраивает, больше это не нужно. Мало VS> того, когда мне недавно нужен был РоС, ЧатГПТ сделал мне C/Asm код за 5 VS> минут, т.е. *тратить время *на написание кода - тоже не надо - это дорого. VS> Организация, в которой я сейчас работаю, подавляющее большинство кода VS> пишется в подписочном ChatGPT (от ошибок в дизайне софта впрочем не VS> спасает). VS> Мало того, я вот недавно был свидетелем горя от ума на этой почве, когда VS> желание прикрутить именно 8237 в мосте ITE к современной платформе через VS> мост PCIe-PCI-ISA и глубокое понимание как работает DMA в современных VS> системах привело к тому, что человек потерялся в маршрутизации этих VS> сигналов: сделал от карты к процу возврат, а от проца к карте - нет, ну VS> типа как-то придумаем, когда ему все говорят астанавитесь, нет возможности VS> субстрактивного декодинга 00-FF портов, они легаси и хардвайред в PCH, нет, VS> я найду как. Ну ок. Способа нет, кроме VM или недокументированных трапов VS> SMM. Чел остановился на VM варианте, с которым всё остальное (сделать всё VS> только на железе) теряет смысл.

VS> On Fri, May 9, 2025 at 10:12 AM Alexander V Soroka wrote:

...
...
1) аппаратное, когда "все стоп! сохраняем все регистры в стеке и прыгаем на прогу обработки прерывания". 2) аппартное, мы выставляем "флаг" в каком-то регистре и идем дальше, если никто не пришел за данными, то они перезаписываются следующими. 3) аппаратное, Учтройство приняло кусок данных, и само инициировало по Прямому Доступу к Памяти (ПДП) перенос данных в некую область Памяти. После этого Устройство продолжает работу. Т.е. Процессор сам по себе, Устройство само по себе, а данные блокируют доступ Процессора к Памяти только на момент "перелива".При этом если Процессор н е"ходит" в той области памяти куда льет Устройство по ПДП, то ничего не тормозится.

VS> _______________________________________________ VS> UANOG mailing list -- uanog@uanog.one VS> To unsubscribe send an email to uanog-leave@uanog.one

-- Best regards, Alexander V Soroka http://www.svr.ua/ AS106-RIPE mailto:alex@euro.net.ua

_______________________________________________ UANOG mailing list -- uanog@uanog.one To unsubscribe send an email to uanog-leave@uanog.one

Valentin Nechayev

8:47 a.m.

New subject: NIC interrupts / IRQs / Cores

hi, Fri, May 09, 2025 at 10:33:42, vsharun wrote about "[uanog] Re: NIC interrupts / IRQs / Cores":

...

Александр Васильевич, Современная сетевая карта - это полноценный комп, это больше не 8237, саундбластер про и десяток их регистров/портов. Драйвера для нее настолько сложны, что нет смысла даже начинать, это сотни мегабайт кода фирмвари и мегабайты кода интерфейса со стороны ОС к этой фирмвари.

Ну обычно таки поменьше:) Весь e1000 в Linux, например, это полмега, из которых, если ужать все switch до конкретной модели, останется 100kB. Сложить кадры в память, добавить описатели к ним (типа, если это TCP, то поднять флаг "подсчитай CRC сам"), слинковать в цепочку, обновить указатель хвоста в регистре сетевухи. И наоборот на приёме. Не сложно по сути, просто надо знать детали. И железо там ближе, чем PHY, это просто прямолинейный автомат — стучатель по памяти. Но то, что одна карта толще по вентилям всего IBM PC AT какого-нибудь — 100%, к гадалке не ходи.

...

Поезд глубокого понимания программирования PIC/DMA ушел, оно нужно тем, кто программят PIC/APIC/DMA, а тем, кто настраивает, больше это не нужно. Мало того, когда мне недавно нужен был РоС, ЧатГПТ сделал мне C/Asm код за 5 минут, т.е. *тратить время *на написание кода - тоже не надо - это дорого. Организация, в которой я сейчас работаю, подавляющее большинство кода пишется в подписочном ChatGPT (от ошибок в дизайне софта впрочем не спасает). Мало того, я вот недавно был свидетелем горя от ума на этой почве, когда желание прикрутить именно 8237 в мосте ITE к современной платформе через мост PCIe-PCI-ISA и глубокое понимание как работает DMA в современных системах привело к тому, что человек потерялся в маршрутизации этих сигналов: сделал от карты к процу возврат, а от проца к карте - нет, ну типа как-то придумаем, когда ему все говорят астанавитесь, нет возможности субстрактивного декодинга 00-FF портов, они легаси и хардвайред в PCH, нет, я найду как. Ну ок. Способа нет, кроме VM или недокументированных трапов SMM. Чел остановился на VM варианте, с которым всё остальное (сделать всё только на железе) теряет смысл.

Я удивляюсь, что 8237 для чего-то в современной платформе ещё живо. Почему его не снесли, когда исчез последний ISA разъём с материнки? -netch-

Volodymyr Sharun

9:33 a.m.

New subject: NIC interrupts / IRQs / Cores

On Fri, May 9, 2025 at 11:47 AM Valentin Nechayev wrote:

...

hi,

Fri, May 09, 2025 at 10:33:42, vsharun wrote about "[uanog] Re: NIC interrupts / IRQs / Cores":

...
Александр Васильевич, Современная сетевая карта - это полноценный комп, это больше не 8237, саундбластер про и десяток их регистров/портов. Драйвера для нее настолько сложны, что нет смысла даже начинать, это сотни мегабайт кода фирмвари и мегабайты кода интерфейса со стороны ОС к этой фирмвари.

Ну обычно таки поменьше:) Весь e1000 в Linux, например, это полмега, из которых, если ужать все switch до конкретной модели, останется 100kB.

Я ж про современные сетевые, 25-100G, с RDMA, RoCE, FCoE

...

Я удивляюсь, что 8237 для чего-то в современной платформе ещё живо. Почему его не снесли, когда исчез последний ISA разъём с материнки?

Ретро. Один из челенджей - на каком самом быстром железе можно запустить голый дос без эмуляции с ISA звуковой (как правило что-то из последнего, где все глюки DMA вылечены, ESS1868/69, Yamaha 719, Crystal), и чтобы нетребовательные в хорошем смысле игры давали звук максимально выжимаемый - это не так просто как кажется. Т.е. General Midi дочки на waveblaster порт, хардварные модификации ямаховских карт, чтобы работал нормально low pass filter и т.п. На текущий момент - это Z87/Z97 (Haswell, т.к. разгоняются легко) с LPC to ISA мостом Fintek (LPC берется из TPM хедера) и висящей от PCH линии LDRQ#1. Стандарт sound blaster'а - он через 8237 DMA, Gravis Ultrasound - тот еще жестче завязан на DMA. LPC до 100й версии чипсетов Интела был полноценной ISA только в сериал варианте, у АМД в процессоре оно, пока трудно всё там.

Valentin Nechayev

8:36 a.m.

New subject: NIC interrupts / IRQs / Cores

hi, Fri, May 09, 2025 at 10:12:31, alex wrote about "[uanog] Re: NIC interrupts / IRQs / Cores": VN>> Описана, да. Но: VN>> 1) Неточные прерывания (imprecise interrupts/exceptions/etc.) в VN>> современных архитектурах не присутствуют. Ну, может, в самых VN>> маргинальных осталось.

...

Тут надо понимать, что в книге точно описаны прерывания "как это работает". И с 90х ничего не поменялось в этом плане. Прерывания трех видов: 1) аппаратное, когда "все стоп! сохраняем все регистры в стеке и прыгаем на прогу обработки прерывания".

Или же ничего не сохраняем кроме текущего адреса и режима привилегий, а сохранение данных отдаём на откуп коду обработчика. Современные архитектуры ведут к этому. Но не так принципиально.

...

2) аппартное, мы выставляем "флаг" в каком-то регистре и идем дальше, если никто не пришел за данными, то они перезаписываются следующими. 3) аппаратное, Учтройство приняло кусок данных, и само инициировало по Прямому Доступу к Памяти (ПДП) перенос данных в некую область Памяти. После этого Устройство продолжает работу.

И эти оба варианта уже не называются прерыванием, по крайней мере у подавляющем большинства авторов и архитектурных документов. Если где-то умудрились назвать "прерыванием" выставление флага в состоянии устройства — покажите точный источник и цитату.

...

Т.е. Процессор сам по себе, Устройство само по себе, а данные блокируют доступ Процессора к Памяти только на момент "перелива".При этом если Процессор н е"ходит" в той области памяти куда льет Устройство по ПДП, то ничего не тормозится.

Нечеткие прерывания это скорее к (2) т к (3) . А (1) ничего не поменялось.

Нет. У понятия imprecise exceptions совершенно чёткий смысл, к которому ни одно из этих вообще не относится. Пусть у нас, например, последовательность команд (x86, Intel syntax) mov mem1, eax inc mem2 Если первая команда получает исключение (скорее всего, страничное, если страницы с mem1 нет или в неё нельзя писать), то вторая не должна быть выполнена, чтобы обработчик мог вернуться туда же. Если же она выполнена, то при возврате мы можем получить некорректное увеличение на 2 вместо ожидаемого 1. Поэтому в процессоре должна быть жёсткая сериализация _видимого результата_ действий по их зависимости по порядку нахождения в потоке команд: пока мы знаем, что первая команда не даст исключения, мы не имеем права писать результат второй. А вот имеем право прочитать mem2 или нет, чтобы подготовить результат — зависит от режима доступа к соответствующему участку памяти (uncached — не можем, writeback, writethrough и т.п. — можем). Аналогично представим себе, что вместо записи в память первая команда — деление (пусть и пишет в регистры, но на x86 и ряде других может дать исключение). В Skylake, например (для более поздних данных не видел) такой конвейер растягивается до 97 команд и 224 микроопераций, в которые транслируются команды. Меня эти цифры реально ужасают, но это следствие чудовищно неравномерных времён доступа к памяти. Так вот, те архитектуры, на которых imprecise exceptions когда-то были разрешены, допускали их на ряд проблем, но только не аппаратные прерывания (то есть от внешних устройств), потому что эти прерывания приходят непредсказуемо, и в этом случае вообще ничего бы не работало. Они допускались только на ошибки, вызванные исполнением собственно кода, и то не на все. И постепенно это устранили, потому что толку в них никакого, добавить разумное упорядочение команд не так сложно. Таненбаум тут, откровенно говоря, лажает. Надо поискать оригинал, какое слово там было исходно, но если он сказал imprecise interrupts, говоря про аппаратные, то это просто глупость и враньё, а если про программные (которые чаще называются исключениями) — то он отстал от реальности.

...

Если же мы говорим о "делении на ноль" то это может быть как аппартное прерывание так и программное,

В современной терминологии это исключительно программное прерывание, потому что инициировано выполнением кода, а не сигналом от внешнего устройства.

...

т.е. Операционка сама, какие-то кванты времени, "смотрит" в "лог событий" и там если видит эксепшн или некое "уведомление о событии" то запускает процесс который с этим что-то делает. Или не делает :-) Посмотрите в ВИнде сколько "ошибок страниц" там пролетает за минуту. И ниче — все живы :-)

Страничные ошибки (page faults) отрабатываются процессором и далее ОС в момент их поступления, вызывая переключение в режим ядра, обработку ситуации и переключение обратно, если не генерируется ошибка доступа. Обработка постфактум через лог событий — не их случай. Я не знаю, с чего вы так решили, но нигде так не делается.

...

А вот теперь скажите мне: если у вас в Процессоре есть 16 ядер, то КАКОЙ ИЗ НИХ должно отвлекаться на прерывание?

Программное прерывание (исключение, в наиболее типичной терминологии) — ровно то ядро, в котором выполнялась команда, выполнение которой вызвало это исключение. И никак иначе. (Возможно, где-то есть варианты, что тяжёлое событие, после которого выполнение вообще невозможно, порождает machine check exception, которое передаётся на другой процессор. Но это отдельный разговор.) А вот аппаратное (от внешнего устройства) передаётся согласно раутингу таких прерываний, и дальше вопрос, как этот раутинг настроен. Могут на одно конкретное ядро. Могут рандомизировать для распределения нагрузки. Оба варианта имеют свой смысл в конкретных условиях.

...

Вопрос еще усложняется когда у каждого Ядра есть свой Кеш "уровня Х", куда заранее подгружается кусок исполняемого кода? Тут такой хаос можно устройить...

На каких современных (хотя бы от 2010) процессорах вы видели управляемую подгрузку заранее в кэш, чтобы там код хранился и не вымывался?

...

Я не хочу сильно углубляться в проблемы "железа и то как пишут Люди", но сейчас вот все это отдается на откуп Компилятору С, который уже сам решает все эти пролемы - т.е. кто что из Ядер должен делать, как настроить Обработчик прерываний и т.п.

Компилятор этим не занимается. Занимается код ОС — при её наличии, рантайм — в случае без ОС. Вероятно, для какого-то AVR/PIC/etc. подключается стандартный рантайм, в котором это реализовано, и именно это вы назвали компилятором. Но это некорректно.

...

Вы на "верхнем уровне" писанины программ этого не видите вообще.

Не видим, да. И не нужно, потому что достаточно гарантий корректности нижнего уровня.

...

Поэтому и получаются глюки - компилятор не имеет "мозга" а работает стандартными кусками кода (конфифгурации).

???

...

И если вы специально не лезете в регистры управления Устройства(микросхем) то вы полностью зависите от Компилятора и того что курили индусы которые написали код этого компилятора :-) Я пишу для низкого уровня , микропроцессоры, и пишу на С99 так, чтобы в коде потом все было как мне нужно (асемблерный код). Полезно использовать https://godbolt.org/ для того чтобы понимать как вот этофсе вот что ты сейчас написал, будет вывернуто в ассемблер.

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

...

И сколько "подвызовов процедур" реально "стоит" твоя вот эта команда с передачей параметров через стек.

VN>> Аппаратные - вообще я не слышал, чтобы такое хоть где-то было, потому VN>> что это недопустимо, чтобы в непредсказуемые моменты тебе VN>> невосстановимо ломало всю работу.

...

Вы ошибаетесь. Ничего не ломается. Просто Процессор складывает в стек часть или все регистры и прыгает по адресу "Обработки прерывания".

Не ошибаюсь. Состояние, которое процессор "складывает в стек", соответствует "архитектурному" состоянию (значения видимых программисту регистров и памяти, без учёта кэша и т.п.) для завершения какой-то команды в промежутке от той, которая самая ранняя ещё выполнялась в момент поступления запроса на прерывание, и до самой поздней, которая только начала выбираться из памяти. Где именно будет зафиксировано состояние в этом диапазоне — зависит от массы факторов, но будет на какой-то точно определённый момент после завершения одной команды и перед началом выполнения другой. (Например, простейший, хоть далеко не лучший вариант, это просто остановить выборку команд и ждать, пока все не выполнятся.) И именно это критически важно, потому что "неточные прерывания", как их описал Таненбаум, это когда такой однозначности нет, разные регистры, разные адреса памяти могут отражать результаты разных позиций в этом диапазоне команд. Именно поэтому это никто сейчас не использует: с такого состояния нельзя корректно восстановить выполнение.

...

Тут ничего не изменилось с 90х годов, просто добавились всякие косвенные и т.п. адресации для удобства. Даташит на любой Процессор открываем и читаем.

Ага, и в нём в случае x86 или ARM не описано как раз самое вкусное для обсуждаемой темы. Интересующиеся выясняют это всё косвенно из экспериментов, или из утечек.

...

В случае одного Процессора, вы будете иметь "лаг-задержку" на время пока Процессор отработает код в прерывании, и вернется в точку откуда прыгал, загрузит спрятанные в стеке регистры, и продолжит работу с того же места. С вашей точки зрения вы даже не увидите что это все было - только "вдруг лаг" по тактам выполнения (строчкам выполнения).

Спасибо, кэп;) Всё так (с мелкими поправками, типа кто именно сохраняет/восстанавливает регистры), но это далеко не всё, что важно в данном контексте.

...

Если же у нас несколько ядер то каждое Ядро это отдельный Процессор. Там уже и своя память и Арбитр Прерываний - т.е. Программа (после компилятора) должна как-то указывать как будут распределяться обработки прерываний среди Ядер. Это про аппаратное я написал.

Да. И для того что поднял автор треда — нужно использовать средства ОС для привязки. Я такое видел, например, с DPDK. Под конкретную сетевую карту выделяется ядро целиком, только одна нить имеет право работать на нём, и прерывания направляются на это ядро. (Если есть аппаратный гипертрединг, "ядро" уже плохой термин. В RISC-V придумали hart == hardware thread. Мне этот термин нравится больше остальных.)

...

Теперь про любимые "типа реал тайм системы" :-) Под этими RTOS сейчас для железа есть то что просто тупо по таймеру выдает "кванты ресурсов на обработку", и потом то же самое: прячер мегистры, указатели, и отдаем память Процессору и новому "треду" или новому куску кода.Это получается НАДстройка НАД аппартными прерываниями как от Устройств так и от Таймеров.

Да.

...

Кому интересно - полистайте исходный код Адупайлота - основной проги БПЛА, которая управляет "типа реал тайм" всем самолетом.

Есть такая штука, угу. Самое смешное, что историческое название от работы на Arduino, но на Arduino её теперь исполнить нельзя — слишком толстая. Нужен минимум STM32 или аналог. И он может работать и поверх Linux.

...

Все RTOS так устроены. И Линукс тоже, просто в нем нет такой жесткой слежки за "квантами вычислений". Я сейчас сильно упрощаю, чтобы мысль свою донести.

Только я не понял, к чему эта мысль в данном обсуждении. VN>> Было в некоторых (например, SPARC до VN>> какого-то момента) для _исключений_, вызванных программными событиями, VN>> типа неподдерживаемой команды, и то не всех (page fault, например, VN>> туда не входил). VN>> Судя по тому, что в POWER точные исключения завезли в 1990, в x86 с VN>> момента его перехода в OoO (PentiumPro - 1996), а в S/370 ещё в 70-х - VN>> он отстал уже к моменту написания книги.

...

Вы не поняли. Я выше описал как это работает, в Книге тоже точно описано. Ничего не поменялось.

Ну кроме того, что imprecise exceptions не имеют никакого отношения к аппаратным прерываниям и вообще вымерли.

...

И ваша "сетевуха" может работать как я писал выше - в одном из трех режимов. Но сейчас все стараются делать (3) чтобы Устройство работало "в иной реальности времени" само по себе, а некий Арбитр должен управлять потоками данных. Иначе полная жопа будет...

Реально то, что я вижу для случаев реализации под большие нагрузки — это что на устройство (сетевая карта) возлагается задача разместить принятый кадр в память и дать свисток процессу, который будет этот кадр разбирать. Или наоборот, читать из памяти и отправлять (ну и оповещать о темпе прогресса). То есть это ваш вариант (3), с поправкой на то, что ПДП контроллер встроен в неё саму.

...

И число ядер тут как раз при чем - Устройство (Сеть) это ПОСЛЕДОВАТЕЛЬНЫЙ ОБМЕН. Т.е. пока летит в сетевом кабеле один пакет, второй никто не примет. Значит Устройство должно принимать все что "нормальное" куда-то в буфер,

Сразу в оперативную память. Может, да, с буфером до одного кадра.

...

выставлять "флаги" а потом Ядра как-то(?) должны весь этот буфер разгребать. И если Ядра быстрые то они стоят, а Устройство тупо принимает пакеты и складывает.

Ну.

...

Можно в Устройство всунуть свой Процессор, очень быстрый, который будет устанавливать "еще один уровень" между Сетью(кабель) и Процессорными Ядрами (верхний уровень). Типа предварительной фильтрации по MAC "а это вообще мне?" . Вы поняли что я написал сейчас ?

Вы ничего не написали, что не было бы (лично мне) известно уже много лет как. Вопрос не в фактах, как я понимаю, а в их связи между собой и обсуждаемой темой. Хотя и в фактах, как вижу, у вас местами странные представления.

...

Вы расплачиваетесь за нежелание "лезть ниже" тем что теряете производительность в 1000 раз примерно :-(.

Чего это?

...

Яркие примеры сейчас - писанина для STM32 любимых контроллеров БПЛА на HAL библиотеках просто уничтожает все эти 70-150МГц таковой частоты :-( оно тупо еле вывозит такие программы.

Проблемы HAL уровня я слышал, хотя лично не доводилось щупать. Но это вопрос того, как этот HAL написан, а не в принципе его наличие.

...

А еще сейчас куча проблем с ИИ, который "в библиотеках", которые неподьемные из-за такой вот наплевательской манеры написани кода вида "и так сойдет, если не хватает мощщи то поставьте проц пошустрее". :-( То эе самое сейчас с "переходом на цифру". Задержки на обработке видео с камеры и передаче этого в радиоканал.

Сколько задержка? Если менее 100 мс то для большинства, кажется, несущественно, это вам не Counter Strike. Ну и от целевого назначения зависит. Для простого FPV-камикадзе, наверно, невыгодно. -netch-

Age (days ago)

Last active (days ago)

List overview

Download

14 comments

5 participants

participants (5)

Alexander V Soroka
Max Tulyev
Valentin Nechayev
Volodymyr Litovka
Volodymyr Sharun

Re: NIC interrupts / IRQs / Cores

tags

participants (5)