Да, Вы правы.
За одним исключением.
Размер Payload определяется содержимым конфигурационных регистров и может быть намного больше чем 256 байт. В частности в используемом нами коммутаторе — это 2048.
Ну и немного конкретизирую Ваш пост. Posted транзакции — это не все транзакции записи в целом, а только транзакции Memory Write и сообщения.

Я начинаю думать, что сценарий 100-180 PCIe устройств — это что-то из обсуждения в наших предыдущих публикациях?
Ежели так, то в наших сценариях не предполагается одновременный доступ ко всем устройствам в отдельно взятый момент времени. Нам важно просто иметь к ним доступ в рамках одного PCIe дерева. Но это не значит что мы будем делить полосу пропускания между ними.

даже если мы тупо гоним из одного PCIe устройства в другое

И еще нужно сказать следующее. Указанный Вами сценарий в реальной жизни — это достаточно редкое явление. Обычно PCIe устройства не имеют собственной памяти, и гнать в него ничего нельзя. Как правило работа с PCIe устройством заключается в том, что Вы сообщаете ему где в Вашей системной памяти находится его (PCIe устройства) буфер и далее это PCIe устройство работает с Вашей системной памятью посредством механизма DMA.

Смотрите — если Ваш хост — это FPGA с чем-то рукописным и один абонент. То в принципе Вы можете приблизиться к заветным 16ГБ/с в одну сторону. И даже к суммарному 32 ГБ/с при независимых потоках в обе стороны. Для этого нужно слать максимально большие пакеты. То есть теоретически физика интерфейса и достаточно низкая latency коммутатора (150нс) — позволяют это сделать.
Если перейти к более реальным вещам. То мы видели производительность порядка 60% от физически возможного при соединении x86 системы с PLX PEX9797 — этот коммутатор имеет внутри DMA и виртуальный NIC. Собственно в данном эксперименте мы работали с PEX9797 как обычным сетевым адаптером и проверяли скорость iperf'ом. На сколько этот показатель можно увеличить — гадать не берусь.
Одновременная работа большого количества устройств на одном root комплексе — это предмет исследований. Но на мой взгляд узким горлом тут будет не коммутатор.

Простите, я не понял Ваш вопрос.
В цитируемой Вами фразе я всего лишь имел в виду, что некорректно просто брать физический предел интерфейса, умножать его на 2 и обещать такой troughput. А именно это обычно и делается производителями в буклетах. Те же упомянутые мной Dolphin так и пишут — up to 32GB/s.

Системный клок в используемых нами рабочих станциях — не очень хорош в плане джитттера.
Error Rate при работе от системного клока при тех же настройках коммутатора — значительно выше.
Ну и в целом не хочется зависеть от материнской платы на таких рисковых длинах. Мы же никак не можем на нее повлиять.
В итоге канал хост-адаптер работает на системном клоке, как любая стандартная PCIe карта расширения, а внешние интерфейсы адаптера — на собственном.
Экономия на паре корпусов клоковой подсистемы в данном случае не покрывает возможные риски.

Мы учли пожелания к предыдущим статьям быть более техничными.

В данный момент — никаких.
На этапе разработки — мы предполагали (и до сих про предполагаем), что в ряде применений будет необходимость изменять стартовую конфигурацию коммутатора либо изменять какие-то его параметры на лету. Конечно, большинство из этих потребностей может реализовать хост система инбэндно — но для этого потребуется специальный драйвер для этого адаптера.
В частности мы предполагали, что нам нужно будет определять тип внешнего кабеля и модифицировать под него параметры приемников/передатчиков.
Для этого мы внедрили CPLD и небольшой DIP-переключатель для задания режимов.
В данный момент CPLD ничего не делает.
Почему именно Lattice?
Просто этот производитель мне нравится. У него очень вкусные и недорогие CPLD, удобная система разработки и хорошая информационная поддержка.

Нет.