динамические тасклеты или рабочие очереди

Предыстория: я пишу модуль ядра для обработки сетевого трафика. Я получаю пакеты, используя перехватчики netfilter. Вся фильтрация выполняется внутри функции ловушки, но я не хочу здесь обрабатывать пакеты. Таким образом, решение - это тасклеты или рабочие очереди. Я знаю разницу между ними, я могу использовать оба, но у меня есть некоторые проблемы, и мне нужен совет.

  1. Решение тасклетов. Предпочтительно. Я могу создать и запустить тасклет для каждого пакета, но кто будет удалять этот тасклет? Функция тасклета? Я не думаю, что это хорошая идея - освобождать тасклет во время его выполнения. Создать глобальный пул тасклетов? Ну, так как на одном процессоре не может быть 2 исполняемых тасклетов, размер пула будет равен количеству процессоров. Но как узнать, когда тасклет доступен для нового использования? Есть только два состояния: shed и run, но нет состояния "done". Хорошо, я, наверное, могу обернуть тасклет какой-нибудь структурой с флагом. Но не будет ли все это слишком излишним?

  2. Решение рабочей очереди. Та же проблема: кто удалит работу? То же «решение», что и для тасклетов?

  3. Решение Workqueue 2. Просто создайте постоянную работу из-за загрузки модуля, сохраните пакеты в какую-то очередь и обработайте их внутри работы. Может быть две работы и две очереди: входящая и исходящая. Но я боюсь, что с таким решением я буду использовать только один (или два) процессора, так как работа не может выполняться на нескольких процессорах одновременно.

  4. Любые другие решения?


person cody    schedule 29.08.2013    source источник


Ответы (1)


Можно использовать высокий приоритет(WQ_HIGH_PRI), не привязанный(WQ_UNBOUND) рабочих очередей и придерживайтесь option3, перечисленных в вопросе.

WQ_HIGH_PRI гарантирует, что обработка начнется как можно скорее. WQ_UNBOUND устраняет узкое место, связанное с одним ЦП, поскольку планировщик немедленно назначает работу любому доступному ЦП.

person TheCodeArtist    schedule 29.08.2013
comment
Спасибо, звучит многообещающе. - person cody; 29.08.2013