netdev - Re: [PATCH] ucc_geth: Rework the TX logic.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <49D22ABC.5050408@freescale.com>
Date:	Tue, 31 Mar 2009 09:37:48 -0500
From:	Scott Wood <scottwood@...escale.com>
To:	Joakim Tjernlund <Joakim.Tjernlund@...nsmode.se>
CC:	Li Yang <leoli@...escale.com>, linuxppc-dev@...abs.org,
	netdev@...r.kernel.org, pku.leo@...il.com
Subject: Re: [PATCH] ucc_geth: Rework the TX logic.

Joakim Tjernlund wrote:
> I am a bit confused, what isn't worth it?

Enabling cacheing on MURAM, at least when used for buffer descriptors. 
The cache line ping-pong would probably outweigh the cost of the 
uncached accesses.

> Currently MURAM isn't used by ucc_geth,

Hmm.  I looked in the driver and saw numerous muram allocations, but I 
didn't try to follow the driver enough to ensure that they were for the 
ring.  I'd assumed it was similar to the CPM1/CPM2 driver.

> 3) as gianfar, dma_alloc_coherent(). I presume this is uncacheable memory?

It would be uncacheable on systems without coherent DMA, but I don't 
think there are any such systems that use gianfar.

> My guess would be 2 or 3. Do they have the same synchronization
> sematics?

No, unfortunately.  PowerPC sync instructions are a bit complicated. 
For example, you can use eieio to sync between reading the interrupt 
status register and checking the ring buffer, if they're both mapped 
I+G, but not if the former is I+G and the latter is cacheable (you need 
a full sync in that case).

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