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

Reply via email to