Hi,
On Mon, Feb 23, 2009 at 12:43 PM, Grant Grundler
<grundler@xxxxxxxxxxxxxxxx> wrote:
> On Mon, Feb 23, 2009 at 11:47:19AM +0530, arun c wrote:
> ...
>> Yes I don't need any lock to protect my data
>> here, as host is write only and target is read only.
>>
>> Here is what I did.
>>
>> typedef command_pkt {
>> u32 valid;
>> ......
>> ......
>> ......
>> u32 data[];
>> }
>>
>> typedef struct my_circ_buf {
>> u32 read_index;
>> u32 write_index;
>> command_pkt_t cmd_pkt[30];
>> } my_circ_buf_t;
>>
>> Host writes commands,
>> makes valid field to VALID,
>> and increments write_index.
>
> I suspect you need/want at least one wmb() between those three steps
> depending on what the remote host is polling.
> The "VALID" field sounds redundant to me and I would drop it.
> Updating the write_index should be enough clue for the remote side
> to know which indexs are valid.
>
This is useful for me when read_index = write_index
It will stop host to overwrite the buffer when there
is unprocessed commands at the target side.
Target never reads write_index here.
>> Target reads commands at read_index,
>> if and only if valid field is VALID and
>> after processing it makes valid field
>> INVALID and increments read_index.
>
> So "VALID" really means "BUSY" or "INFLIGHT".
>
> Don't really need share both VALID bit and head/tail indexes.
> Avoiding sharing of the index could conserve a fair amount of CPU cycles
> on the host side.
I really don't understand this, for me host and target
is sharing a buffer sitting at the PCI space.
The target is exposing its SDRAM over PCI and
the buffers are local to target and over PCI to host.
In this case how to avoid sharing?
>
>> It seems to be working for me
>> I need to investigate further for any
>> cache coherency issues, write now
>> I am running with dcache off.
>
> This is arch specific. Host side is usually cache coherent.
> IIRC, some embedded PPC are not.
>
Regards,
Arun C
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
