Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Оптимизация LwIP
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Системы на ПЛИС - System on a Programmable Chip (SoPC)
Veg@
Код
    struct pbuf *q, *pq;
    char* ptr;
    . . .
    ptr = pq->payload;
    for(q = p; q != NULL; q = q->next) {
        memcpy(ptr, q->payload, q->len);
        ptr += q->len;
    }
    . . .

Данный код используется в LwIP для расположения содержимого буферов в памяти последовательно. На его выполнение затрачивается почти половина всего времени отправки UDP-пакета (0.14мс / 0.31мс). Для каждого пакета по 1484Б происходит две итерации.
Возможно ли ускорить это действие (DMA) или как-нибудь обойти (например, заранее располагая буферы в памяти в нужном порядке) ? Спасибо.
Железо: DK-NIOS-2S60N (StratixII), стандартная сборка Nios - Full featured.
sergeeff
Почитайте здесь : http://old.nabble.com/Tunning-TCP-in-Lwip-td7158695.html. Там много советов по оптимизации параметров.
Veg@
Цитата(sergeeff @ Feb 27 2010, 01:43) *
Почитайте здесь : http://old.nabble.com/Tunning-TCP-in-Lwip-td7158695.html. Там много советов по оптимизации параметров.

Да, но большинство советов относится к оптимизации TCP и ответа на свой вопрос я также не нашел.
sergeeff
А что не понятно? Если ваш UDP пакет уходит за две итерации, значит размер одного pbuf мал для его размещения целиком. По крайней мере, можно передавать за одну итерацию.
Veg@
Цитата(sergeeff @ Feb 27 2010, 13:26) *
А что не понятно? Если ваш UDP пакет уходит за две итерации, значит размер одного pbuf мал для его размещения целиком. По крайней мере, можно передавать за одну итерацию.

Размер одного буфера 1536Б. И вообще, я думаю, не обязательно весь отправляемый пакет помещается в один буфер; возможно, он составляется из нескольких (напр., заголовки+данные).
sergeeff
Цитата(Veg@ @ Feb 27 2010, 15:14) *
Размер одного буфера 1536Б. И вообще, я думаю, не обязательно весь отправляемый пакет помещается в один буфер; возможно, он составляется из нескольких (напр., заголовки+данные).


Ну и чего вы тогда от lwip хотите? Раз вы не можете точно знать все лежит в одном буфере или вам надо раскрутить цепочку pbuf, значит кроме этого for-цикла вариантов нет. Может собака зарыта в вашем медленном memcpy? По крайней мере те memcpy, которые обычно в стандартных библиотеках находятся, мягко говоря, по скорости не ах.
Veg@
Функция memcpy выполняется довольно медленно, поэтому я и спрашиваю о конкретных способах обхода данного цикла.
vadimuzzz
код memcpy доступен, идет в стандартной поставке. проверьте, не происходит ли побайтное копирование, это реальный затык для 32-битного проца.
http://www.embedded.com/columns/technicali...equestid=754901
если все равно медленно - тогда DMA
Veg@
Цитата
если все равно медленно - тогда DMA

Т.е. с DMA тоже свои определенные проблемы могут возникнуть или только реализация усложняется?
dspx
Цитата(Veg@ @ Feb 27 2010, 22:22) *
Т.е. с DMA тоже свои определенные проблемы могут возникнуть или только реализация усложняется?


А под ниос нет контроллера ethernet, работающим в режиме DMA? т е чтобы он мог читать данные напрямую из памяти, минуя системную шину. У хилых ethrnet так можно сконфигурить.
sergeeff
А что автор так уперся в оптимизацию цикла for(...)? Это что, самое узкое место в его проекте?
vadimuzzz
Цитата(Veg@ @ Feb 28 2010, 01:22) *
Т.е. с DMA тоже свои определенные проблемы могут возникнуть или только реализация усложняется?

усложняется немного, но достаточно, чтобы задать вопрос о целесообразности LWIP(или о глубокой оптимизации последнего). так что там с побайтным копированием? самому интересно. вот еще ссылка на эту тему: http://forum.niosforum.com/forum/index.php?showtopic=5795
Цитата
А под ниос нет контроллера ethernet, работающим в режиме DMA? т е чтобы он мог читать данные напрямую из памяти, минуя системную шину. У хилых ethrnet так можно сконфигурить.

проблема не в контроллере, они все в режиме DMA работают. поганое место - очередь пакетов и т.п., это все программно обруливается, и как показал топикстартер, довольно криво (медленно).
sergeeff
Цитата(vadimuzzz @ Feb 28 2010, 06:00) *
усложняется немного, но достаточно, чтобы задать вопрос о целесообразности LWIP(или о глубокой оптимизации последнего). так что там с побайтным копированием? самому интересно. вот еще ссылка на эту тему: http://forum.niosforum.com/forum/index.php?showtopic=5795

проблема не в контроллере, они все в режиме DMA работают. поганое место - очередь пакетов и т.п., это все программно обруливается, и как показал топикстартер, довольно криво (медленно).


На самом деле топикстартер ничего не показал, а только сказал, что цикл for() крутится довольно медленно (как ему кажется). Вопрос совсем в другом. Как этот самый for() отрицательно влияет на общую производительность приема/передачи по UDP? На сколько процентов падает реальная скорость? На 1%, 5%, 10%, 50%? За что бороться то? Уверен, что оптимизированная memcpy, для начала, покажет, что к чему.
Veg@
Цитата(sergeeff @ Feb 28 2010, 02:55) *
А что автор так уперся в оптимизацию цикла for(...)? Это что, самое узкое место в его проекте?
Вероятнее всего.
Цитата
так что там с побайтным копированием?
Благодарю за интерес. Сейчас временно этим вопросом не занимаюсь, отпишусь на след. неделе.
Veg@
Цитата
На самом деле топикстартер ничего не показал, а только сказал, что цикл for() крутится довольно медленно (как ему кажется).
Почему кажется? Замеры производились с помощью Perfomance Counter; что в нем может быть неоднозначного?
sergeeff
Вы запустите какой-нибудь обмен по UDP с компьютером в реальной сети и, скорее всего, убедитесь, что вы не над тем голову себе ломаете.
Veg@
Цитата(sergeeff @ Mar 1 2010, 02:22) *
Вы запустите какой-нибудь обмен по UDP с компьютером в реальной сети и, скорее всего, убедитесь, что вы не над тем голову себе ломаете.
Именно так я и измеряю скорость передачи данных в канале.

Цитата(vadimuzzz @ Feb 28 2010, 06:00) *
так что там с побайтным копированием?
Действительно, копирование производилось побайтно из-за отсутствия выравнивания по "long" границе. Выравнивание дало ощутимое прибавление производительности: время копирования 1400Б сократилось с 0.14мс до 0.04мс (cpu: 85МГц).
Итого: пропускная способность канала возросла с 38Мбит/с до 56Мбит/с.

Для тех, кому интересно, прикрепляю реализацию функции memcpy().
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.