Hi,
On Mon, Feb 23, 2009 at 1:01 PM, arun c <arun.edarath@xxxxxxxxx> wrote:
> 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?
>
Yes I am wrong here. I really don't need to
share them. sorry for the noise.
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
