Технологии

Да, в общем случае для двух независимых Ethernet-интерфейсов (с отдельными сетями) процессору нужны два отдельных MAC-контроллера, каждый со своим интерфейсом R(G)MII или аналогичным, подключенным к своему PHY.

Стандартная архитектура в SoC вроде Allwinner или Rockchip подразумевает 1:1 соотношение MAC к PHY для data-интерфейса (MII/RMII/GMII), потому что это параллельные сигналы, и подключение двух PHY напрямую приведёт к конфликтам — данные просто перемешаются или потеряются. MDIO-шина (для управления) может быть общей для нескольких PHY (до 32 по спецификации, с адресами), и один MAC может управлять несколькими PHY через неё, но это не меняет ситуацию с данными: одновременно активен только один PHY на MAC.

Если нужно несколько портов на одном MAC, то обычно используют внешний свитч-чип (например, Realtek RTL8367 или подобный), который подключается к MAC как один PHY, а уже свитч раздаёт на несколько физических портов. Но это не две отдельные "сетки" в смысле двух независимых интерфейсов в Linux (eth0 и eth1 с разными IP), а один интерфейс с свитчингом.

Насчёт производительности в твоём исходном сценарии: если бы каким-то хаком (мультиплексером или custom-логикой) заставить работать по очереди, то да, обслуживание sequential, пакеты в очереди, латентность UDP вырастет (минимум в 2 раза + overhead), плюс риски потерь при одновременном трафике. Но на практике это не реализуемо без серьёзных модификаций hardware, и Embedded Linux (kernel drivers вроде sunxi_emac или rk_gmac) не поддерживает такое out-of-the-box — драйверы ожидают один PHY per MAC.

Если в твоём SoC уже есть несколько MAC (например, в RK3399 два Ethernet MAC), то просто подключай по PHY на каждый. Иначе — добавь внешний Ethernet-контроллер по USB/PCIe.