История изменений

И это не оскорбление, а простая констатация медицинского факта.

Вот Ваша ссылка. Открываем прямо 1.4 Functional Block Diagram, Figure 1-1 shows the AM335x microprocessor functional block diagram.

Ниже приведена функциональная блок-схема, прямо там же, на стр. 5 приведённого Вами документа (удивляюсь – зачем приводить документ, который либо не читали, либо хреново поняли?).

Вот то, что там нарисовано, это всё, что Вам нужно знать о внутреннем устройстве данного SoC. Даже не особо разбираясь в том, что там с PHY творится, Вам это не нужно. Особо глубоко лезть тоже. На ARM только на Raspberry Pi 4 сетка сделана более-менее по-честному. В остальных случаях она на USB болтается. Точно так же, как и в данном случае EMAC (2-port) 10M, 100M, 1G IEEE 1588v1, and switch (MII, RMII, RGMII) это всё «serial», который через L3/L4 interconnect заведён на проц.

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

Отдельно я замечу что в приведённом Вами документе нет раздел 10 Interconnects, Figure 10-1. L3 Topology. Т.е., что Вы за говнину сюда приволокли и зачем, лично мне не понятно.

Ладно, пусть будет документ по Вашей ссылке. Дальше открываем приведённую на стр. 18 из Вашего документа ссылку, тоже PDF. Идём на стр. 2013 документа и читаем внимательно в разделе 14.3.1.1 Interrupt Pacing:

The Interrupt pacing feature limits the number of interrupts that occur during a given period of time. For heavily loaded systems in which interrupts can occur at a very high rate (e.g. 148,800 packets per second for Ethernet), the performance benefit is significant due to minimizing the overhead associated with servicing each interrupt. Interrupt pacing increases the CPU cache hit ratio by minimizing the number of times that large interrupt service routines are moved to and from the CPU instruction cache.

Несложно заметить что это значение для свича, который там встроен. Собственно, с ним как-то и надо работать чтобы выполнять преобразования пакетов. Или Вы предполагаете прямо на процессоре софтсвитч организовать? Тогда у меня для Вас ещё более плохие новости…

Жирным я специально для долб… эээ… для Вас лично выделил значимое значение. Ваш свитч Ethernet будет в лучшем случае пропускать 148 800 пакетов в секунду. Дальше простой расчёт – умножаем число пакетов в секунду на размер eth-фрейма в байтах округлённо. Т.е., 148 800 * 1500 = 223200000 байт в секунду. Или, по-просту, 223M в секунду. Это максимальная скорость, с которой будет работать Ваш свитч (и то если будет, т.к. пакеты надо преобразовывать, а это дополнительные расходы, сжирающие ресурсы).

Отдельно замечу что в документации не сказано какой именно размер пакетов принимается. А то, если размер пакета по 64 байта, то всё будет ещё печальнее. Если Вы посмотрите на доки для ряда свичей, то там отдельно этот момент оговаривается. Размер пакета и его тут надо отдельно смотреть.

Если Вы вознамеритесь на самом проце сорганизовать софтсвитч (игнорируя аппаратный), то тогда Вы упрётесь в то, о чём я и говорил выше. Тут вся сеть болтается на USB 2.0, следовательно, скорости будут примерно такими, которые я и обозначил. И то, что Eth поддерживает 1G вовсе не означает того, что ровно мегабит реальных данных будет обрабатываться устройством.

В общем, милейший, не вводите людей в заблуждение, а то люди по простоте душевной от микрухи за условные «пять баксов» будут ожидать просто очешуенной производительности.

Я, конечно, тоже погорячился насчёт DPDK. Просто сразу не посмотрел спеки. DPDK здесь лишний, т.к. обработки гигабитного потока реальных данных я не ожидаю. Максимум 300-400М и то, если повезёт.

Умоляю. Не пишите больше ерунды, хорошо? =)))

И это не оскорбление, а простая констатация медицинского факта.

Вот Ваша ссылка. Открываем прямо 1.4 Functional Block Diagram, Figure 1-1 shows the AM335x microprocessor functional block diagram.

Ниже приведена функциональная блок-схема, прямо там же, на стр. 5 приведённого Вами документа (удивляюсь – зачем приводить документ, который либо не читали, либо хреново поняли?).

Вот то, что там нарисовано, это всё, что Вам нужно знать о внутреннем устройстве данного SoC. Даже не особо разбираясь в том, что там с PHY творится, Вам это не нужно. Особо глубоко лезть тоже. На ARM только на Raspberry Pi 4 сетка сделана более-менее по-честному. В остальных случаях она на USB болтается. Точно так же, как и в данном случае EMAC (2-port) 10M, 100M, 1G IEEE 1588v1, and switch (MII, RMII, RGMII) это всё «serial», который через L3/L4 interconnect заведён на проц.

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

Отдельно я замечу что в приведённом Вами документе нет * раздел 10 Interconnects, Figure 10-1. L3 Topology*. Т.е., что Вы за говнину сюда приволокли и зачем, лично мне не понятно.

Ладно, пусть будет документ по Вашей ссылке. Дальше открываем приведённую на стр. 18 из Вашего документа ссылку, тоже PDF. Идём на стр. 2013 документа и читаем внимательно в разделе 14.3.1.1 Interrupt Pacing:

The Interrupt pacing feature limits the number of interrupts that occur during a given period of time. For heavily loaded systems in which interrupts can occur at a very high rate (e.g. 148,800 packets per second for Ethernet), the performance benefit is significant due to minimizing the overhead associated with servicing each interrupt. Interrupt pacing increases the CPU cache hit ratio by minimizing the number of times that large interrupt service routines are moved to and from the CPU instruction cache.

Несложно заметить что это значение для свича, который там встроен. Собственно, с ним как-то и надо работать чтобы выполнять преобразования пакетов. Или Вы предполагаете прямо на процессоре софтсвитч организовать? Тогда у меня для Вас ещё более плохие новости…

Жирным я специально для долб… эээ… для Вас лично выделил значимое значение. Ваш свитч Ethernet будет в лучшем случае пропускать 148 800 пакетов в секунду. Дальше простой расчёт – умножаем число пакетов в секунду на размер eth-фрейма в байтах округлённо. Т.е., 148 800 * 1500 = 223200000 байт в секунду. Или, по-просту, 223M в секунду. Это максимальная скорость, с которой будет работать Ваш свитч (и то если будет, т.к. пакеты надо преобразовывать, а это дополнительные расходы, сжирающие ресурсы).

Отдельно замечу что в документации не сказано какой именно размер пакетов принимается. А то, если размер пакета по 64 байта, то всё будет ещё печальнее. Если Вы посмотрите на доки для ряда свичей, то там отдельно этот момент оговаривается. Размер пакета и его тут надо отдельно смотреть.

Если Вы вознамеритесь на самом проце сорганизовать софтсвитч (игнорируя аппаратный), то тогда Вы упрётесь в то, о чём я и говорил выше. Тут вся сеть болтается на USB 2.0, следовательно, скорости будут примерно такими, которые я и обозначил. И то, что Eth поддерживает 1G вовсе не означает того, что ровно мегабит реальных данных будет обрабатываться устройством.

В общем, милейший, не вводите людей в заблуждение, а то люди по простоте душевной от микрухи за условные «пять баксов» будут ожидать просто очешуенной производительности.

Я, конечно, тоже погорячился насчёт DPDK. Просто сразу не посмотрел спеки. DPDK здесь лишний, т.к. обработки гигабитного потока реальных данных я не ожидаю. Максимум 300-400М и то, если повезёт.

Умоляю. Не пишите больше ерунды, хорошо? =)))