Привет ! у кого есть "час та натхнення" я рекомендую почитать книжку: 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