From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: "Moore, Eric" <Eric.Moore@lsi.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: HELP: Is writeq an atomic operation??
Date: Fri, 2 May 2008 16:12:34 -0700 [thread overview]
Message-ID: <200805021612.34281.jbarnes@virtuousgeek.org> (raw)
In-Reply-To: <0631C836DBF79F42B5A60C8C8D4E822901047B2F@NAMAIL2.ad.lsil.com>
On Friday, May 02, 2008 3:40 pm Moore, Eric wrote:
> Is a 64bit write to MMIO registers an atomic operation when using the
> writeq API?
>
> My concern is when I send 64bit data via writeq, will it be sent out as
> two 32 bit writes? If so, is it possible that another CPU be sending
> the data at the same time. Meaning can I write the 1st 32bit data from
> CPU-A, meanwhile CPU-B is writing his 32bit data at the same time, and
> CPU-A didn't complete the full 64bit in one shot. If this could occur,
> is there an API that I can use to make sure the entire data sent in one
> atomic operation?
>
>
> Here is a trace from pci express analyzer. I'm sending
> 0x0800010000000000 to the adress DD1400C0 using writeq. Notice that in
> the TLP header it sent a 32bit Memory write with data length of two.
>
> Trace follows:
>
> Link Tra(597) Downstream 2.5(x1) TLP(1992) Mem MWr(32)(10:00000) TC(0)
> TD(0)
> _______| EP(0) Attributes(01) Length(2) RequesterID(000:02:0) Tag(8)
> _______| Address(DD1400C0) 1st BE(1111) Last BE(1111) Data(08000100
> 00000000)
> _______| VC ID(0) Explicit ACK(Packet #1195) Metrics # Packets(2)
> _______| Time Stamp(0003 . 120 181 840 s)
I think this is normal; PCIe defines transactions in terms of dwords, to a 64
bit write would indeed be a transaction packet with a length of two (it can
go up to 4k). AFAIK though transactions are processed as a whole, so even a
4k write (as long as it's generated as a single transaction) won't result in
the device seeing e.g. 2x2k writes. I'd have to double check the routing
rules to be 100% sure though, maybe in some cases the fabric is allowed to
break up transactions (?).
Jesse
next prev parent reply other threads:[~2008-05-02 23:12 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-02 22:40 Moore, Eric
2008-05-02 22:46 ` Roland Dreier
2008-05-03 0:42 ` H. Peter Anvin
2008-05-03 14:35 ` Alan Cox
2008-05-03 17:40 ` H. Peter Anvin
2008-05-03 22:37 ` Benjamin Herrenschmidt
2008-05-04 17:01 ` Roland Dreier
2008-05-02 22:50 ` Andi Kleen
2008-05-02 23:03 ` Moore, Eric
2008-05-02 23:13 ` Andi Kleen
2008-05-02 23:04 ` Roland Dreier
2008-05-02 23:20 ` Moore, Eric
2008-05-03 0:10 ` Roland Dreier
2008-05-02 23:12 ` Jesse Barnes [this message]
2008-05-03 0:41 ` H. Peter Anvin
[not found] <0631C836DBF79F42B5A60C8C8D4E822901047B1D@NAMAIL2.ad.lsil.com>
2008-05-02 22:32 ` David Miller
2008-05-02 22:43 ` Roland Dreier
2008-05-02 22:49 ` David Miller
2008-05-02 22:49 ` Moore, Eric
2008-05-02 22:53 ` Roland Dreier
2008-05-02 23:13 ` Moore, Eric
2008-05-02 23:21 ` Roland Dreier
2008-05-02 23:31 ` Moore, Eric
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200805021612.34281.jbarnes@virtuousgeek.org \
--to=jbarnes@virtuousgeek.org \
--cc=Eric.Moore@lsi.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome