Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
New API (одан әрі NAPI деп аталады) - Linux ядросындағы желілік құрылғылар үшін үзілістерді азайту әдістерін пайдалану интерфейсі. Мұндай тәсіл пакеттерді қабылдаудың жалпы шығынын азайтуға бағытталған. Идеясы - кіретін хабарламаларды бірден өңдеуге болатын жеткілікті мөлшерде болғанша кейінге қалдыру.
New API (also referred to as NAPI) is an interface to use interrupt mitigation techniques for networking devices in the Linux kernel. Such an approach is intended to reduce the overhead of packet receiving. The idea is to defer incoming message handling until there is a sufficient amount of them so that it is worth handling them all at once.
Мотивация
Желілік драйверді іске асырудың қарапайым әдісі - әр келіп түскен пакет үшін үзіліс сұранысын (IRQ) беру арқылы өзекті үзіп тастау. Алайда IRQ-ға қызмет көрсету процессор ресурстары мен уақыты жағынан қымбатқа түседі. Сондықтан, жоғары жылдамдықты желілерде тікелей іске асыру өте тиімсіз болуы мүмкін, ядроны секундына мыңдаған пакеттермен үнемі үзіп тұрады. Нәтижесінде жүйелердің жалпы өнімділігі мен желілік өткізу қабілеті төмендейді. Сауалнамалау үзіліске негізделген өңдеуге балама болып табылады. Ядро жүйеге кіретін желілік пакеттердің кіруін үзіліссіз мерзімді түрде тексеріп отыра алады, бұл үзілісті өңдеудің үстіртін жояды. Алайда, оптималды дауыс беру жиілігін белгілеу маңызды. Тым жиі жүргізілетін сауалнамалар әлі келмеген кіріс пакеттерін қайта-қайта тексеру арқылы процессор ресурстарын ысырап етеді. Екінші жағынан, сауалнама өте сирек кіретін пакеттерге жүйелік реактивтілікті азайту арқылы кіруді енгізеді және егер кіретін пакеттер буфері өңделместен бұрын толтырылса, ол пакеттерді жоғалтуға әкелуі мүмкін. Компромистік ретінде Linux өзегі әдетте үзіліске ұшыраған режимді қолданады және тек кіретін пакеттер ағыны белгілі бір шектен асқанда ғана дауыс беру режиміне ауысады, бұл желі интерфейсінің "салмағы" деп аталады.
A straightforward method of implementing a network driver is to interrupt the kernel by issuing an interrupt request (IRQ) for each and every incoming packet. However, servicing IRQs is costly in terms of processor resources and time. Therefore, the straightforward implementation can be very inefficient in high speed networks, constantly interrupting the kernel with the thousands of packets per second. Overall performance of the system as well as network throughput can suffer as a result. Polling is an alternative to interrupt based processing. The kernel can periodically check for the arrival of incoming network packets without being interrupted, which eliminates the overhead of interrupt processing. Establishing an optimal polling frequency is important, however. Too frequent polling wastes CPU resources by repeatedly checking for incoming packets that have not yet arrived. On the other hand, polling too infrequently introduces latency by reducing system reactivity to incoming packets, and it may result in the loss of packets if the incoming packet buffer fills up before being processed. As a compromise, the Linux kernel uses the interrupt driven mode by default and only switches to polling mode when the flow of incoming packets exceeds a certain threshold, known as the "weight" of the network interface.
Артықшылықтар
Ауысулар туғызатын жүктеме ядроның ауызша сұрауын қажет еткенмен де азаяды. Пакеттерді қайта тапсыру ықтималдығы төмен, ал тапсырыссыз пакеттерді өңдеу бұдан басқа бөтелке болуы мүмкін. Егер ядро барлық кіріс пакеттерді өңдеуге қабілетсіз болса, оларды тастау үшін ядроға ешқандай жұмыс істеудің қажеті жоқ: олар желілік картаның кіріс сақиналық буферіне жазылады. NAPI-сіз ядроға қызмет көрсетуге уақыт бар-жоғына қарамастан, әрбір кіріс пакетін өңдеуге тура келеді, бұл шабуылға әкеледі.
The load induced by interrupts is reduced even though the kernel has to poll. Packets are less likely to be re ordered, while out of order packet handling might be a bottleneck otherwise. In case the kernel is unable to handle all incoming packets, the kernel does not have to do any work in order to drop them: they are simply overwritten in the network card's incoming ring buffer. Without NAPI, the kernel has to handle every incoming packet regardless of whether there is time to service it, which leads to thrashing.
Тарих
NAPI Алексей Кузнецов, Джамал Хади Салим және Роберт Олссонның үш жылдық еңбегі болды. NAPI-ді қосуға алғашқы күш-жігер қауымның кейбір мүшелері тарапынан қарсылық танытты, алайда Дэвид Миллер NAPI-ді қосуды қамтамасыз ету үшін көп жұмыс істеді. Бұл жобаға қатысуға дейін Уппсала университетінің желісінде көптеген тәжірибелік сынақтар жүргізілді. Шын мәнінде, www. Слю. se NAPI-ге негізделген алғашқы өндірістік ОЖ болды және ол әлі күнге дейін NAPI-ге негізделген Bifrost / Linux маршрутизаторларымен қамтамасыз етіледі. Бұл уақытта PKTgen трафик генераторы да пайда болды. Pktgen кеңінен нақты әлемдегі трафиктен туындамаған NAPI сценарийлерін сынау үшін пайдаланылды.
NAPI was an over three year effort by Alexey Kuznetsov, Jamal Hadi Salim and Robert Olsson. Initial effort to include NAPI was met with resistance by some members of the community, however David Miller worked hard to ensure NAPI's inclusion. A lot of real world testing was done in the Uppsala university network before inclusion. In fact, www. slu. se was the first production NAPI based OS and is still powered to this day by NAPI based Bifrost/Linux routers. The pktgen traffic generator was also born around this time. Pktgen was extensively used to test NAPI scenarios not induced by real world traffic.