[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
MBUF memory allocation
- Date: Thu, 17 Sep 1998 16:09:40 -0500
- From: jmonkman at frasca.com (Jay Monkman)
- Subject: MBUF memory allocation
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
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.