Максимальный размер пакета данных, какой? Опции

[Vincent Vega]

какое максимальное количество данных можно передать в компьютер за одну транзакцию PCI?

пока что представляю о наличии регистра cacheline size, который задаёт эту самую длину транзакции. Но этот регистр - 8-битный, из чего можно сделдать вывод, что максимальная длина транзакции - 256 слов. А хотелось бы 2k ( Возможно ли это организовать?

нашёл упоминание о режиме адресации cacheline wrap mode, с помощью которого вроде бы можно "склеить" несколько транзакций - правда пока не пойму чем ограничивается количество передаваемых данных в этом режиме

[Raven]

Максимальный размер burst'а на PCI зависит о целого ряда факторов, так как он определяется взаимодействием компонентов по всей длине прохождения данных (от PCI устройства до оперативной памяти). Попробую перечислить основные:

1) Возможности Host-bridge, а также всех PCI-to-PCI bridges (если таковые есть) по пути от Host bridge до локальной PCI bus, на которой и находится интересное устройство. Поток данных надо буферизировать внутри моста (а размер буферов никогда не бывает бесконечным ), т.к. шина по другую сторону моста может оказаться занятой в отдельные моменты времени. Соответственно, вполне может оказаться, что не шибко большой объем буферной памяти в бридже будет ограничивать длину пакета. Правда, нужно сказать, что современные мосты вроде обладают вполне приличными характеристиками в этой области (по буферизации), но помнить об этом факторе не помешает.

2) Возможностями самого PCI device, будь то master или slave. Хотя идеология построения PC на сегодняшний день предполагает, что для достижения сколько-нибудь приличных скоростей передачи данных по PCI соответсвующее устройство должно быть PCI Master, т.е., само должно заботиться о перемещении данных в нужное место, и само должно стараться обеспечить нужную скорость (а значит, иметь, например, свой собственный DMA на борту). Т.е., весь этот разговор имеет смысл вести, имея в виду в первую очередь все-таки Master-устройства. А конкретное Master-устройство еще должно уметь работать с пакетами длиной в 2K, и не факт, что ваше на такое способно.

3) Но предположим все же, что первые два пункта позволяют передавать пакеты длиной в 2K. Тогда дело остается за "малым" (говорю с иронией, потому что это "малое" может оказаться совсем не таковым): обеспечить правильные настройки PCI обрудования (и мостов, и devices). Тут-то и надо вспомнить о Latency Timer'е, который задает гарантированное *минимальное* время занятия шины (реальная длительность пакета может быть и больше, если никто другой не пытается выйти на шину по истечении заданного в Latency Timer количества тактов). Размер Latency Timer'а - 8 бит, т.е., если ваше устройство не пренебрегает правилами PCI, гарантировать можно только длительность PCI транзакции в (255 + небольшой хвостик в пару-тройку) тактов. Другое дело, что если на этой же шине остальные устройства малоактивны и не будут часто лезть со своими запросами, то весьма приличная часть транзакций вашего устройства может иметь длину пакета и в 2K, и даже больше (если соответствующий bridge(s) позволит ему это). Настраивает Latency Timers во всех PCI устройствах соответствующий драйвер, и должен он это делать, вообще говоря, на основе информации, извлекаемой из MIN_GNT & MAX_LAT всех PCI устройств. Да только, похоже, пока штатные драйвера обходятся упрощенными алгоритмами обработки этой информации, и лепят значения Latency Timer, исходя из принадлежности устройства к тому или иному классу устройств попросту (т.е., если device скажем, просто Slave, и это какой-нить vendor-specific, то дадут ему 8 тактов (к примеру), а если это сетевой контроллер и мастер, то получит он, скажем 0x80). Вывод: придется делать еще и свой драйвер, который, кроме прочего, будет обеспечивать нужную настройку Latency Timer.

Вот такие вот пироги. Надеюсь, не сильно утомил? ;-)