Пакетная передача данных PCI (packet burst). Старая новая тема.

[PredatorAlpha]

Предлагаю вернуться к этой теме. Есть ли возможность пакетного чтения с устройства PCI в слейв режиме??? Кому-то это удавалось, иначе чем через 2 32-битных слова ММХ или 4 32-битных слова SSE ?

[PredatorAlpha]

Развивая мысль - в интелловской архитектуре процессор генерирует барстовые чтения в следующих случаях:
1) вычитка MMX регистра командой movq (2 32-битовых слова читаются барстом), вычитка SSE регистра (4 32-битных барста - непроверено для всех процессоров). Для невыровненных данных могут быть варианты. Барст в 2 или 4 цикла вряд ли может кого-то вдохновить, и обеспечить приемлимую скорость чтения по шине PCI (~ 6-12 МБайт/сек).
2) И самое интересное. Процессор генерирует барстовые чтения/записи для вычитки/сохранения строки кэша.
3) Мне не известен другой способ задействовать барсты по шине. Если кто-то знает, очень интересно услышать.

Подробней о проблеме строк кеша для устройств PCI.
По-умолчанию кеширование памяти для PCI устройств отключено (точнее, включена политика WC, при которой кэш для чтения не используется, а для записи используется ограничено - по этой причине запись в PCI-память происходит быстрее, чем чтение).
Теоретически можно включить кеширование, установкой соответствующих битов в дескрипторах страниц (биты PCD, PWD и PAT). Это не проблема. (Естественно, строки кэш-памяти нужно вручную сбрасывать сразу после чтения, что бы не наткнуться на старые данные, и политика не должна допускать спекулятивных чтений, но это не проблема).
Но есть ещё регистры MTRR, которые помечают целые зоны как некешируемые (точнее с политикой WC). При этом настройки в дескрипторах страниц, мягко говоря, игнорируются.

Никто не игрался с регистрами MTRR, что бы объявить память кешируемой, или что бы виндовсовский плаг-энд-плэй мапировал память нужных устройств PCI в соответствующие области? Есть ли другие варианты для барстовых операций?

[Ochkarik]

PredatorAlpha,
http://electronix.ru/forum/index.php?showtopic=32110

стр 31:

"“Limited PCI bursting with x86 architecture”
Reads originated from an x86 (Intel) architecture CPU destined to a PCI slave device
(such as PLX 9050) will never be bursted. This is a x86 IA32 limitation. By their nature,
reads from a PCI slave device are to uncached memory. (The PCI device is mapped into
uncached memory). As a result, reads are blocking (another read can’t emerge from the
CPU until the earlier read is completed). So this leads to the situation that the largest
”burst” of data is confined to the largest ”single” read that the x86 CPU can perform
to uncached memory. Currently, this is a 64 bit read, done using the instruction MOVQ
r64, mem. So, the largest read burst that you can get by using an x86 CPU to read
a PCI slave is a 64 bit, or ”two” data phase burst. (Pretty darn short burst, since it
is not even a full cache line). Tricks can be played that could allow a faster read, but
they are involved and error prone. For instance, the PCI slave device’s memory could
be mapped as cacheable (likely writethrough mode would be best). Then when the PCI
slave device was read by the CPU execution unit, the cache unit would pull in a whole
cache line at a time. This could be done for consecutive addresses. The result would be
”bursting” of x86 cacheline size (64 bytes per line), or 16 PCI data transfer clocks. (Not
that fantastic either, but better). Unfortunately, you then have to flush the CPU cache
before transferring again from the same address. (That is usually detrimental to system
performance, so no one does it). In summary, the x86 will block on a read to uncached
memory. This limits the ”burst” size to the size of the largest single ”read” transaction
to uncached memory, which is 64-bits, 4xbytes, 2 PCI data clocks, all byte enables. If
you play games with the cache, and mark the memory as write through, then you can
get 64 bytes reads, but the cost is flushing the entire CPU cache whenever address reads
will repeat. This is so expensive that it defeats the gains realized in the larger bursts, so
it usually is not done. (Plus getting an OS interface that allows WBINVD cache flush
instruction to be executed is a hassle). As to burst writes, chipset (Intel 440BX and VIA
MVP3, for example) architectures won’t burst more than 4 LWords at a time out of main
memory to a PCI target device. This is because uncached writes coming out of the CPU
don’t gather in posted write buffers in the chipset in greater numbers than 4 LWords at
a time to allow greater bursts. You won’t get greater bursts, no matter how hard you
try. You can get limited bursting if you work at it. The recommended combination is: 1.
Map the device memory as USWC (write combined) if possible. NT has functions that
allow for this, and some other OS do as well. This facility resets the x86 architecture
MTRR registers to give a USWC format to some memory. Some video drivers call this
interface; try looking at a video driver sample in the NT DDK. 2. Use a chipset with
lots of posted write buffers, and one which can combine sequential writes to linearly
sequential addresses into a single burst. A chipset that can combine sequential partial
writes into a single PCI burst is the best. 3. Use the MOVQ mem, m64 instruction in
a tight loop rather than the REP movsd instruction. The former at least outputs 64-bit
partial writes, the latter only does 32-bit partial writes. Write performance with bursts
of 4 LWords originating from an x86 architecture CPU is approximately 50MB/s. High
performance devices such as the 9054 are set up as bus masters so they can master their
own traffic with longer bursts. The 9054 can achieve transfer performance of 122MB/s.

PS правда не зню насколько этому верить можно.
PPS про политику кеширования - увы ничем не могу подсказать... если разберетесь - интересно было бы узнать)

[PredatorAlpha]

Да, я читал это. Мы когда столкнулись с проблемой производительности перевели плату на мастер. Но интересно, решал кто-нибудь эту проблему в слэйве?

[Ochkarik]

мы очень мало им занимались, а каком то виде проект оживили, но в потоковую скорость передачи  уперлись - памяти на плате мало оказалось. так что по совокупности пришлось переходить на мастер...
контроллер PCI вы сами программируете, или готовый используете?

[PredatorAlpha]

Готовый. Встроенный в DSP от Техас Инструментс.

[Ochkarik]

в нем же мастер тоже есть? нафига вам слейв?)
ага... в слейве вроде бурст поддержан...говрят)
в нем cache line size правильно запрограммирован? чтение на границу кэша выровнена?
кроме того таблица 2 страница 20. и далее...
раздел 7.2.3 Memory Read Line Transactions...
там его сначала запрограммить надо правильно - вы уверены что там все верно?

[PredatorAlpha]

Мастер есть, и основной поток данных идёт через него, но есть часть данных, что хранятся в памяти устройства, и драйвер их тоже должен учитывать. В принципе, терпимые мелочи, до сотни байт на каждое прерывание к драйверу (раз в 10-50 мс). Эти данные постоянно обновляются, и кидать их через мастер - это тормозить ДСП, тем более что они нужны драйверу только в момент его всплытия. Впринципе, не критично, пара-десяток лишних микросекунд на вызов, но зачем их держать в ядре??
В слейв режиме всем управляет процессор (ну и арбитр шины, который может попросить проц подождать). При этом, если процессор не просит потоковой передачи (нет сигнала на ножке процессора), соответствующий сигнал не будет выставлен на контакте FRAME# разъёма PCI, и барстовая операция не пройдёт, даже при том, что плата оную операцию поддерживает.
Кстати, для барстовой операции не обязательно нужна команда Memory read Line, достаточно Memory Read/Memory Write с выставленым сигналом FRAME#. Если не ошибаюсь, проц команду Memory read Line вообще не инициирует (не вполне уверен для случая вычитки/записи кеша), и оная используется только для обмена между платами. Её отличие от стандартного чтения - это чёткое указание, что будет вычитана вся линейка кеша.
В том беда, что интелловский проц (и АМД тоже) выставляет соответствующую ножку лишь при ограниченном наборе операций, (например при стандартном копировании rep movd он даже не думает напрячься) и если отбросить чисто служебные (типа сохранения/загрузки контекста задачи, контекста сопроцессора, дескриптора сегмента), остаются следующие: вычитка/запись регистра ММХ и SSE, и загрузка и запись строки кеша. Для первого случая барст короткий (8 или 16 байт), и нужно сохранить/восстановить контекст сопроцессора искуственно (в ядре это обязательно), плюс взаимодействие с мультимедиа регистрами геморойное. Во втором случае это уже 64 байт, кроме того, пока обратился к первому слову в строке кэша, другие уже на подходе. Это более интересно.
Мы скорее всего не будем переводить слейв на барст, устраивает то что есть. Но мне интересно, не получалось ли у кого-то. И нет ли альтернативных способов инициировать барст в процессоре (на соответствующей ножке).

[urock]

Да, друзья... Вы меня обрадовали)) Работаю нас первым своим серьезным проектом: пытаюсь научить ПЛИС Virtex 2 и PC общацца друг с другом по шине PCI в burst режиме. В железе реализовал поддержку burst записи в режиме таргет (с использованием PCI-X IP core от Xilinx естественно), оказалось даже просто на первый взгляд и стал ускоренно читать Уолтера Они WDM (драйверы до этого не писал вообще) чтобы изменить существующий драйвер (на старой плате раньше вместо Virtexa стоял ASIC PLX PCI контроллер, работающий в режиме мастер). Думал еще чуть-чуть все пойму и сделаю, а тут выясняется, что компьютер не будет генерировать burst режим для таргет устройств... Ну чтож, я и не думал, что все будет просто, буду реализовывать мастера на Virtexe. Если можно, я тут буду спрашивать глупые вопросы, ок? )

Например один уже есть: если я правильно понял Уолтера, то для начала операции DMA пересылки в режиме bus master надо настроить оборудование, записав в него значение начального адреса пересылки + размера пересылки. А потом скомандывать ему начать транзакцию. Все это делается записывая соответствующие значения во внутренние регистры устройства, отображенные, например, в память, так? Вопрос: кто будет инициировать эти транзакции? надо думать PCI мост под управлением драйвера? а мое устройство, соответственно, тогда должно выступать в роли таргета? получается, что оно одновременно должно поддерживать два интерфейса, мастера и цели?

Буду очень признателен за более менее развернутый ответ!

[PredatorAlpha]

..... Думал еще чуть-чуть все пойму и сделаю, а тут выясняется, что компьютер не будет генерировать burst режим для таргет устройств... Ну чтож, я и не думал, что все будет просто, буду реализовывать мастера на Virtexe. Если можно, я тут буду спрашивать глупые вопросы, ок? )

Это ничё... Мы столкнулись с проблемой за месяц до передачи заказа заказчику. До этого гоняли на не сильно загруженых потоках, всё было ОК, а потом, как стали гонять на нормальных, драйвер стал долго шуршать на передаче данных. Хорошо, что был встроенный в ДСП контроллер, что поддерживал мастер, и сильно переделывать не пришлось.

Например один уже есть: если я правильно понял Уолтера, то для начала операции DMA пересылки в режиме bus master надо настроить оборудование, записав в него значение начального адреса пересылки + размера пересылки. А потом скомандывать ему начать транзакцию. Все это делается записывая соответствующие значения во внутренние регистры устройства, отображенные, например, в память, так? Вопрос: кто будет инициировать эти транзакции? надо думать PCI мост под управлением драйвера? а мое устройство, соответственно, тогда должно выступать в роли таргета? получается, что оно одновременно должно поддерживать два интерфейса, мастера и цели?

Нет. Вся роль PCI моста сводится к тому, что бы на твой запрос шины ответить тебе через некоторое время "шина готова!". А дальше уже ты, как мастер, пишешь по адресу, что тебе выделил твой драйвер (естественно, что это должен быть ФИЗИЧЕСКИЙ адрес, физически непрерывный и несвапируемый кусок). Как ты это реализуешь - через ДМА, что ты сам реализовал на ПЛИСе или как-то ещё - твои проблемы.  И кто будет инициатором пересылки - это тоже твои заботы.

Кстати, занимать шину надолго - дурной тон. Нужно пересылать кусочками 64-256 байт, освобождая шину и потом требуя вновь. Может и мост "попросить" закруглиться, соответственно после этого нужно правильно продолжить работу.

[urock]

может я не так сформулировал... Я понимаю, что инициатором барст транзакции будет мое мастер устройство на ПЛИС. Но как ты сам сказал, драйвер должен выделить адрес моему мастеру. Как я понял это делается например командой в драйвере WRITE_PORT_ULONG. На мой взгляд инициатором этой транзакции (это же транзакция??) на шине будет выступать что-то (какое-то физическое устройство, CPU через мост либо сам мост) на стороне компьютера (я вот и не понимаю это как раз). Тогда мое ПЛИС устройство будет уже как раз целью в транзакции передачи адреса начала барст пересылки. Может быть такое, что устройство будет и мастером и целью одновременно? или я что-то не так понимаю?

[PredatorAlpha]

Устройство может быть и мастером и слейвом. Когда кто-то пишет/читает в память твоего устройства, устройство есть слейвом. Это может быть память конфигурации, в которой содержатся вендор/девайс, (начиная со смешения 0х40 могут быть твои произвольные регистры, переменные), или же память, что мапируется виндосовским плаг-анд-плэем на память компьютера (может не быть).
Когда твоё устройство само запросило шину и делает там какую-то операцию, оно есть мастером.
Естественно, в один момент времени оно не может быть и мастером и слейвом. Кому арбитр дал шину, тот и мастер. К кому обращаются - тот и слейв.
Драйвер выделяет буфер в оперативке компьютера, в которую мастер должен писать. Адреса для платы назначает виндовсовский плаг-анд-плэй, и драйвер на это никак не влияет (как правило).

[urock]

Ок. Ситуация проясняется, спасибо)

[urock]

Есть ли возможность пакетного чтения с устройства PCI в слейв режиме???

Так вы тут говорите про операцию чтения с устройства. а если надо записать в память устройства? в Limited PCI bursting with x86 architecture разделе сказано, что старый чипсет не поддерживает burst write блольше чем 4LWORD. Не знаете, свободны ли современные чипсеты (например Intel P45) от этого ограничения?