On Fri, Jul 29, 2005 at 12:43:34PM -0700, David S. Miller ([EMAIL PROTECTED]) wrote: > From: Evgeniy Polyakov <[EMAIL PROTECTED]> > Date: Fri, 29 Jul 2005 20:55:06 +0400 > > > Unmapping is repeatedly being done in this driver - update_address() and > > tlb_flush() does the thing. > > Current code does skb freeing when it's slot needs to be used for the > > next skb. > > So this numbers already include mapping/unmapping. > > BTW, this reminds me now that if we put this kind of change in > we should work to resolve the issues that prevent packet > mmap() from working properly on virtual cache architectures. > > In fact, I am to understand that currently only x86 even > tries to use packet mmap in the existing userland implementaitons. > I could be wrong, as I haven't looked at the pcap library stuff > in a long time. > > If there is cache coloring conflict, kernel stores to physical > locations may not show up in userspace correct, thus D-cache > flushing or proper coloring of userland addresses is necessary. > The latter is cheaper due to lack of D-cache flushing, obviously.
Code has d-cache flushing, but it is nop on x86, so it's affect can not be measured in my environment. I wish I had more time to port 2.6 to one of custom 440 ppc board. > Another thing missing are proper memory barriers, and some portable > way for a packet_mmap userland code to know what barriers to use > in order to synchronize with kernel updates to the packet mmap > ring buffer area. Yes, it is completely missed in this module. -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html