Re: mutual exclusion locks over PCI memory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> 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.

> 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 an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux