On Fri, Jul 29, 2005 at 09:34:56AM -0700, Max Krasnyansky ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> >Couple of numbers...
> >Remapping of the physical page took about 25-50% less time than 1500
> >bytes copying using memcpy().
> >And 15 times faster just after reboot, i.e. without anything in the
> >cache.
> >
> >CPU is Xeon with HT enabled:
> >cpu family : 15
> >model : 2
> >model name : Intel(R) Xeon(TM) CPU 2.40GHz
> >stepping : 7
> >cpu MHz : 800.384
> >
> >
> >1.
> >packet_mmap_test: 1000 remaps took 1495 usec.
> >packet_mmap_test: 1000 copyings took 1988 usec.
> >
> >2.
> >packet_mmap_test: 1000 remaps took 1406 usec.
> >packet_mmap_test: 1000 copyings took 2613 usec.
> >
> >3. And just after reboot, when there is nothing in cache:
> >packet_mmap_test: 1000 remaps took 1387 usec.
> >packet_mmap_test: 1000 copyings took 20173 usec.
> >
> >4. Yet another "just after reboot":
> >packet_mmap_test: 1000 remaps took 1295 usec.
> >packet_mmap_test: 1000 copyings took 14889 usec.
> >
> >Above copying is being done using arbitrary kernel virtual address
> >as source address and with PAGE_SIZE addition to it before each
> >memcpy().
>
> I'm almost convinced that remap can brake even with ring buffer at 1500
> sizes. However we're talking about total per packet overhead here. At some
> point you have to _unmap_ the thing once user-space app is done with it.
> With ring buffer it's "memcpy()/kfree_skb()" where with mmap it's
> "remap()/unmap()/kfree_skb()".
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.
> Max
--
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
