[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4d812a88-90d8-4376-a0bb-7faa6d0491d4@CMEXHTCAS1.ad.emulex.com>
Date: Tue, 14 Jan 2014 06:33:56 +0000
From: Somnath Kotur <Somnath.Kotur@...lex.Com>
To: David Laight <David.Laight@...LAB.COM>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC: "davem@...emloft.net" <davem@...emloft.net>,
Kalesh Purayil <Kalesh.Purayil@...lex.Com>
Subject: RE: [PATCH net 2/2] be2net: Need a delay before processing CQE
after 2nd mbox register write
> -----Original Message-----
> From: David Laight [mailto:David.Laight@...LAB.COM]
> Sent: Wednesday, January 08, 2014 3:02 PM
> To: Somnath Kotur; netdev@...r.kernel.org
> Cc: davem@...emloft.net; Kalesh Purayil
> Subject: RE: [PATCH net 2/2] be2net: Need a delay before processing CQE
> after 2nd mbox register write
>
> > From: Somnath Kotur
> > Due to Host platform synchronization issues between the mbox RDY bit
> > polled status and the completion of the DMA for the CQE, it is
> > preferable that the Host always wait for the RDY bit to transition to
> > 1 after the 2nd mbox register write and always follow that with a
> > short wait for the valid bit in the CQE, before processing the CQE.
>
> While I don't doubt that a delay(1) fixes the problem it doesn't seem an ideal
> solution.
> I've not looked at what the code is doing (or how often it does it) but either
> delay(1) is far, far longer than is necessary or it might not be long enough and
> some kind of retry loop is required.
>
> It might even be that the driver is just missing a memory barrier.
David,
The memory barrier by itself did not work, however like you said polling on the valid
Bit to be set seems like the right solution as the time for the mbox-completion DMA to finish/reach the host
may not be deterministic.
Thanks
Som
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists