MBUF memory allocation

[jmonkman at frasca.com (Jay Monkman)]

	----------
	From:  Eric Norum[SMTP:eric at skatter.USask.Ca]
	Sent:  Thursday, September 17, 1998 1:14 PM
	To:  Jay Monkman
	Cc:  rtems-snapshots at advicom.net
	Subject:  Re: MBUF memory allocation

	First, let me state that I do not know all the detals on the way the

	860 cache works........

	That makes 2 of us. There are separate instruction and data 
	caches. Each is 4K, 2-way set associative. In order to leave
	some sections of memory uncached, while caching the rest, 
	the MMU must be used. The MMU has 2 32 entry TLBs (one each
	for data and instructions). Valid page sizes are 1K, 4K, 16K,
	512K, 8M. If I understand all of this correctly, I want to 
	use no more than 32 of those TLB entries for the data. 
	Otherwise, there's a penalty when it has to look up the
	entry in main memory. Memory that is used in DMA transfers 
	can't be cached since the MPC860 doesn't implement snooping 
	to maintain cache coherency.

	I'm not sure that it's adequate to just put the mbuf clusters in  
	non-cacheable memory.  You would probably have to put all the mbuf  
	space in non-cachable memory, too since the network code might put  
	headers in an mbuf.  And what happens if we want to implement a  
	`zero-copy' option?  Then the user I/O buffer would have to be
placed  
	in non-cacheable memory, too!

	OK. I had thought all of the packet, including the header would
	be in the clusters. Zero copy would definitely complicate things. 
	Is it likely to happen soon? 

	Wouldn't it be better to just flush the cache entries for the mbuf  
	to memory before starting the DMA output operation, and mark the  
	cache entries `invalid' for an incoming packet?

	I was looking for simple, reasonably efficient means of using
	the caches. I've never done anything with caches or MMUs before,
	and don't want things to be too complicated. In all the Motorola 
	documentation, it says to make DMA memory not cacheable. It
	seems like your suggestion would work, but it makes me nervous
	to go against the documentation; especially when it's documented
	in several places.