NIOSnew, ты б приоткрыл еще предметную область и желаемые параметры.
Ибо Гиг-поток в 100М/с действительно Ниосу не потянуть, тем более с TCP/IP-шизой, которая разрабатывалась под убогие каналы связи лет 30 назад. Только ОС Альтерную включаешь и стек какой-нибудь, сразу 300 К коду нарастает, и там реализовано хорошо если десятую часть от "большого и свежего" стандарта TCP/IP.
У нас, допустим, хоть и Гиг-режим передачи, но там данных от силы 10М/с, просто Eth используется как среда передачи даже полудуплексная и на приличное расстояние. UDP вполне достаточно, если просто гнать какое-то видео, а никакая Линда сверху не стоит и не занимается своими многозадачными и мультипротокольными извратами по тому же каналу. Даже можно в UDP-реализации без Ниос заложить посылку запроса на повторную передачу пакета, если вдруг какой-то потерялся из-за случайного нейтрино и битой им CRC. Или можно не запрашивать, а брать прошлое содержимое того места памяти, куда не пришел пакет. На экране сильно это не отразится

Хотя в рамках локальной сети предприятия сколько не пингуй, допустим, -- пакеты никогда не теряются при обычной жизни без дёрганья проводов, так что надо смотреть на dest-условия по помехам или дребезгу контактов, чтоб просто восстанавливалось всё как-то автоматом хоть через полсекунды после окончания возмущения.
По поводу начального поста -- рекомендую сварганить на Nichestack проект для имеющейся платы с 2 нитями, первая из которых будет гнать любую пургу по TCP/IP в один из двух каналов, другая -- читать из альтернативного, считать и принтфовать М/с раз в секунду, а выходы каналов закоротить. Выше этой цифры не подняться никогда, а только можно попробовать то же самое с UDP

Чем "круче" реализация TCP/IP, тем она медленнее будет работать. Простейшая может даже не сильно отличаться от UDP, если только источник кусками большими шлёт в свой сокет, память накристалльная со всех сторон, пакеты длинные собираются приёмником, смотрящим только заголовки, тоже в большой буфер, помех никаких нет...