В общем, в одной ethernet сети по производственной необходимости оказалось наше устройство на STM32F107 и
много других, которые шлют UDP broadcast.
Так как это ethernet broadcast, приходится принимать все пакеты, потом сбрасывать, когда ясно что не нам.
В итоге периодически затыкается контроллер, так как есть и другие задачи.

Хочу разбить на 2: один микроконтроллер с ethernet будет фильтровать IP пакеты, другой делать другие задачи.
Как бы его и так хватает, это чисто раутер с 802.15.4 250 килобит на IP.
Если бы не затыкался. Какой взять не очень большой микроконтроллер с ethernet?
Хорошо бы еще канал пошире для обмена с другим микроконтролером, но это вряд ли.
Наверное, обычный SPI.

Думал поставить Wiz5100 для фильтра бродкаст пакетов, но он же, наверное, пропустит UDP бродкаст пакет?

Что это за устройства такие, что broadcast-ами загадили всю сеть? И кто это придумал слать UDP с broadcast MAC-адресом?

А какой мак адрес должен быть в UDP запросе, который должен быть получен несколькими адресатами?

Для этого используется IP multicast (для передачи сообщения нескольким адресатам). MAC-адрес в этом случае формируется по определённым правилам, а тут описано по каким.

Broadcast MAC-адрес используется только в ARP-запросах, но они-то точно не должны вешать сеть.

правильнее сказать должен быть использован....

В общем, использование для отправки какой-либо информации UDP с broadcast MAC-адресом - неправильное решение, поэтому и вопрос был - почему так сделано. При таком подходе и большом потоке данных можно заглушить половину устройств в сети, что и имеем. Ни один MAC-контроллер не умеет фильтровать пакеты с broadcast MAC-адресами, а вот при использовании multicast есть такое понятие как hash table. Данная hash table и используется MAC-контроллером для пропуска необходимых multicast MAC-адресов (тех что в ней прописаны) и фильтрации всех остальных.

"В жизни все не так как на самом деле"

Спасибо, интересная теория. Моя задача не найти "кто прав, кто виноват", а придумать решение.
Имеем устройства, без которых нам не жить, и которые посылают именно UDP broadcast с MAC broadcast.
Это данность.

Не верю, что это нельзя решить в прошивке. Верю, что может не хватить знаний/опыта/времени, и второй МК как костыль тогда вполне годное решение при условии, что уж для него знания/опыт/время есть. А вот это как раз не просматривается.
Может быть, тупо приладить дешёвый домашний маршрутизатор и настроить его на фильтрование?

В какой "прошивке"? Можно решить. И решается. Но времени больше ни на что не остается.
100 байтовый пакет занимает 10 микросекунд обработка. За столько же приходит следующий.

Ну все верно. Не хватает ресурсов на работу, потому что задолбили пакетами - ставь выделенный обработчик. А поставить 2 одинаковых проца - дорого? Зачем элементную базу то плодить?

Можно кстати красиво решить: Ставьте в сеть 2 ваших устройства, на первом, что делает дело, выключайте UDP вообще, на втором создавайте TCP соединение с первым, и пусть он пакеты фильтрует, и те что к устройству по ТСР отдает первому, тот обрабатывает и возвращает обратно. Тогда даже плату переразводить не надо, просто 2 штуки поставить.

А, просто, поставить более мощный процессор? Не с 72 МГЦ, а, например, с 720 МГЦ ? Или свет клином именно на этом сошелся?

То была не теория, а элементарные правила, как должна осушествляться передача одной информации несколькии адресатам при использовании ethernet. Раз уж так сделано, то решение - только более мощный процессор, т.к. если бы использовались пакеты с multicast, их можно было бы фильтровать на уровне MAC железно, Вам же придётся задействовать ресурс процессора.

пока Вы не локализуете узкое место - говорить об направлении решения проблемы, мягко говоря не профессионально.
где затык то? обработка пдп, сборка на IP уровне, или где?

в тех стеках что общедоступны, обычно не оптимально по скорости код написан.
так-же важен размер памяти под кванты приёма пдп. если длина мусорных пакетов 100 байт, то делать больше 150-200 байт входные буфера не правильно.
так-же присмотритесь к обработчикам копирования, перемещения, выделение, освобождение и прочих по работе с памятью...

Лечить, естественно, нужно корень, в меру возможности доступа к его авторам, но пока можно приделать костыли.
(Анекдот на эту тему слышал об эмблеме софтверной компании: сверху перечёркнутый красным жук, в центре велик, внизу грабли, всё на фоне перекрещенных костылей
Если даташиты все есть, в прерывании от Eth можно узнать первые байты пришедшего пакета и выкинуть его, если FF. Без проходов по официальным слоям стека это может занять 1 мкс.
Также вдруг в железке есть свойство запретить к приёму какие-то MAC-адреса совсем, от особо шумящих...
API своё надо прошерстить на предмет как можно более низких запретов.

Говорят, костыль нужен, как должно быть неважно.


Какие-то запретить можно, но broadcast mac нет, его примут все устройства.