Планирование опроса NAPI для выполнения через регулярные промежутки времени

Я просмотрел несколько сообщений (в Stackoverflow и за его пределами) по этой теме. В настоящее время я работаю над изменением драйвера i40e-2.0.30 для сетевой карты Intel X710.

Благодаря этому иллюстрированному сообщению в блоге (https://blog.packagecloud.io/eng/2016/06/22/monitoring-tuning-linux-networking-stack-receive-data/), понимание кода драйвера стало намного проще.

Мой пост особенно касается механизма опроса NAPI. Я понимаю, что функция опроса NAPI срабатывает при поступлении пакета, и если объем работы, проделанной при получении пакетов, превышает выделенный бюджет, опрос NAPI продолжается; иначе опрос останавливается.

Основываясь на этой информации, я изменил свой драйвер, чтобы он продолжал опрашивать, поступает ли конкретная подпись данных в определенную очередь (используя директор потока), например. Пакеты UDP на порту XXX для 10 000 циклов опроса. Но я стараюсь максимально исключить возможность прерываний.

Таким образом, вот мои основные вопросы. Смогу ли я запланировать проведение опроса NAPI в определенный момент времени? Например, я хочу, чтобы опрос NAPI выполнялся каждые 500 мс и мог длиться 20 мс. Например, я буду ожидать свой пакет во время T мс, в то время как я могу начать опрос во время (T-10) мс и остановить опрос в ( T + 10) мс. Это может, я мог бы уменьшить использование прерываний. Прямо сейчас я сбрасывал прерывания каждые 10 000 циклов опроса.

Любое объяснение или ссылка на это было бы действительно полезно.

Спасибо, Кушал.


person Cooshal    schedule 07.09.2017    source источник
comment
напр. Пакеты UDP на порту XXX. Почему ваш драйвер для контроллера Ethernet связан с портами TCP/UDP? Похоже, вы не поддерживаете модель TCP/IP или правильную модульность кода. Я пытаюсь максимально исключить возможность прерываний. -- Ваша цель ошибочна. Вероятно, вы снизите (а не улучшите) производительность. См. stackoverflow.com/questions/23574203/< /а>   -  person sawdust    schedule 08.09.2017
comment
@sawdust: привет! Спасибо за ответ. Я также видел ваш ответ stackoverflow в данном URL-адресе. Моя цель — установить синхронную связь между двумя хостами и обеспечить верхнюю границу джиттера принимающей стороны. это было причиной, я пытаюсь устранить как можно больше прерываний. Примером Flow Director может быть пульс, необходимый для синхронной связи. Я еще раз просмотрю ваш ответ для более глубокого понимания. еще раз спасибо   -  person Cooshal    schedule 08.09.2017
comment
Еще раз привет @sawdust, я пытался реализовать несколько вещей в эти выходные. Я попытался вызвать планирование NAPI и опрос NAPI через регулярные промежутки времени. Итак, моя цель состояла в том, чтобы попытаться максимально избежать прерываний Rx и, скорее, вызывать опрос NAPI в течение ожидаемого времени прибытия пакета (например, каждые 500 мс). Я попытался вызвать napi_schedule для каждого события тика временного интервала. Похоже, это так не работает. Любые предложения по этому поводу? или я пробую неправильный подход здесь? Любые материалы/отзывы будут ценными. Спасибо.   -  person Cooshal    schedule 10.09.2017
comment
Вы смотрели исходный код ядра для примеров? перекрестная ссылка Free Electrons очень удобна. Ваше стремление избежать прерываний Rx, насколько это возможно, является ошибочным с точки зрения IMO, потому что NAPI предназначен не для этого. Возможно, вам следует подключить концентратор Ethernet и использовать Wireshark (на другом ПК) для мониторинга входящего и исходящего Ethernet-трафика вашего целевого хоста. Похоже, вы не понимаете существования других протоколов, таких как ARP, ICMP и DHCP, которые будут генерировать неожиданные кадры.   -  person sawdust    schedule 12.09.2017
comment
хорошо, вы правы. именно поэтому я тестировал свои настройки, устанавливая порты в неразборчивом режиме. это похоже на то, что wireshark делает для целей мониторинга. Да, я недавно изучал исходный код ядра. Каким-то образом в моем процессе/шагах должен быть недостаток. Я пытаюсь понять это. Спасибо. Отпишусь дальше, если что-то выясню.   -  person Cooshal    schedule 12.09.2017