Проблема 1GbE Jumbo в QNX6.3.2

[MikeB]

Требуется помощь в решении следующей проблемы.
Имеем hardware с PPC750GX+MV64460 и BSP под QNX6.3.2.
"Железо" должно принимать по Ethernet UDP поток порядка 500 Мб/с.
Реальное ограничение менее 200 Мб/с. Корни проблемы ведут к отсутствию
поддержки транзакций "больших" (Jumbo) пакетов в io-net и качеству подсистемы
io-net. Вариант решения (c форуов) портировать io-pkt и самим
подкорректировать драйвер (найти dvnp-*.so ). Со вторым понятно.
Как решить вопрос подсистемы io-pkt в QNX6.3.2 на PPC ?

[Александр Варварик]

А возможность перехода на старшие версии QNX рассматривали ?

PS. Вроде по этому вопросу были какие-то рекомендации через техподдержку SWD. Что-то вы попробовали и не получилось ?

[MikeB]

А возможность перехода на старшие версии QNX рассматривали ?

PS. Вроде по этому вопросу были какие-то рекомендации через техподдержку SWD. Что-то вы попробовали и не получилось ?

Спасибо за внимание к нашей проблеме.
Рассматривали. Производитель hardware ответил, что не сможет сформировать версию BSP под 6.4.x (реально BSP собирал QSSL по договору). Перебрать BSP под 6.4.x в принципе можно, заключив договор с QSSL или партнерами (SWD) - цена и сроки не понятны. Можно самим заняться, но временные затраты не представляем (надо набирать программные компоненты из 6.4.х BSP другого hardware).
Минимальный путь просматривается портированием io-pkt и корректировкой драйвера devn-mv64360 (что уже написано, но не отлажено, т.к. нет сетевого уровня).
Нужен компетентный совет, как поступать. Готовы рассмотреть любые предложения.

[Олег Большаков]

По моему личному мнению, если на QNX 6.3.2 ничто принципиально не держит, то лучше перейти на QNX 6.4.1 (или 6.5). В 6.4 появился io-pkt (в том числе с поддержкой драйверов io-net), поддержка wi-fi, Advanced Graphics TDK и High Availability Technology включены в базовую поставку. Можете сами посмотреть, что изменилось:

 - Release Notes QNX SDP 6.4.0
 - Release Notes QNX SDP 6.4.1
 - Release Notes QNX SDP 6.5.0

По поводу подготовки BSP Вы также можете обратиться к нам. У нас есть опыт подготовки BSP как для наших заказчиков, так и для иностранных, в том числе и для QSS. С PPC тоже работали. Если Вас заинтересовал такой вариант, то свяжитесь с нами по электронной почте или через форму обратной связи, думаю, что детали лучше обсудить по почте или по телефону.

[Александр Варварик]

MikeB, если будете обращаться к нам, сразу надо думать о том, что нам потребуется процессорная плата на все время разработки и период поддержки. Если такой возможности предоставить нам аппаратуру нет, то ее надо будет купить, за ваш счет. Без аппаратуры мы не возмемся за разработку, доработку или пересборку. В запросе надо будет указать, в каком составе BSP вам необходим (сеть, диски, USB, графика ....).

[Александр Варварик]

Кстати, если ничего не поменяется, то я буду в Киеве 2 марта на семинаре, который проводит Контрон. Если есть вопросы, которые надо осветить, то готов по ним подготовится.

[MikeB]

Кстати, если ничего не поменяется, то я буду в Киеве 2 марта на семинаре, который проводит Контрон. Если есть вопросы, которые надо осветить, то готов по ним подготовится.

Есть следующий блок-вопрос.
В процессе сборки CompactPCI многопроцессорной системы наткнулись на конфликт CP6000 и XCalibur 1002 по шине CPCI. Как мы поняли конфликт связан с различной функциональностью (master-slave) для модулей. Вышли из положения тем, что X-ES изменил в инициализацию шины и мы отказались от обмена по PCI шине, только Ethernet (через backplane). И здесь ряд вопросов: 1) Как CPCI на уровне PCI и PCI-X и Konton поддерживают многопроцессорные архитектуры ? Типовая архитектура, примеры ? Вариант протокола (логическая часть) ? Использование ПДП для транзакций ? Наличие каких-либо драйверов для таких архитектур ?

[Александр Варварик]

  MikeB, блок вопросов понятен, только, как я понимаю, большей частью это аппаратные вопросы и к нам имеют отдаленное отношение.

[MikeB]

MikeB, блок вопросов понятен, только, как я понимаю, большей частью это аппаратные вопросы и к нам имеют отдаленное отношение.

Это вопросы области системной интеграции и ПО, как мне кажется. Спецификация PCI предусматривает возможность периферийному устройству PCI быть мастером. Пример - DMA контроллер PCI моста периферийной платы. И как правило эти возможности аппаратно поддержаны (PLXTech, Altera, Xilinx, ...). Тем не менее каких-либо программных продуктов, кроме ddk производителей чипов найти не удалось. Понятно, что обмен данными в системе - задача интегратора системы и эта задача комплексная. "Железо" должно позволять, ПО должно реализовать. И если нет чего-то готового, то нужен программист уровня ОС (протокол, драйвер, компоненты API). И тут интересен Ваш опыт, если Вы решали подобные задачи или располагаете информацией. Ну хотя бы в методологическом плане. А иначе как использовать продукты производителей узлов и Kontrona в частности ? Всегда нанимать интегратора системы ? Но и в этом случае для выдачи грамотного ТЗ надо понимать возможности и проблемы.

[Александр Варварик]

Стандарта на сетевой обмен по шине CPCI или PCI я не знаю, по этой причине наверное нет стандартный реализаций, хотя такая возможность в спецификациях на шину заложена. конечно для реализации такого обмена требуется разработка ПО. Мы не видим проблем написать соответствующий сетевой драйвер, который с одной стороны обеспечивает работу с "PCI" шиной, а с другой стороны опирается на стандартный сетевой стек, на архитектуру QNX эта задача укладывается очень логично. Думаю, вы и сами можете это сделать, если у вас есть соответствующие программисты.
Подобные задачи мы решали.

[MikeB]

Благодарю Олега Большакова за оказанную помощь.
После небольшой доработки драйвера для MV64460 получили на прием честных 380 Мб/с на 4к UDP пакетах, хотя исходный драйвер проработан довольно поверхностно и слабо использует аппаратные механизмы Marvell. При тщательной переделке можно достичь лучшего.
Всех благ и с наступающим праздником.