Re: [RFC] Zero-copy sniffer. Reincarnation #1. Numbers.

2005-08-01 Thread Evgeniy Polyakov
On Fri, Jul 29, 2005 at 11:58:57PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: > 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 repeatedl

Re: [RFC] Zero-copy sniffer. Reincarnation #1. Numbers.

2005-07-29 Thread Evgeniy Polyakov
On Fri, Jul 29, 2005 at 11:46:13AM -0700, Max Krasnyansky ([EMAIL PROTECTED]) wrote: > Evgeniy Polyakov wrote: > > >>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_

Re: [RFC] Zero-copy sniffer. Reincarnation #1. Numbers.

2005-07-29 Thread Evgeniy Polyakov
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

Re: [RFC] Zero-copy sniffer. Reincarnation #1. Numbers.

2005-07-29 Thread David S. Miller
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 in

Re: [RFC] Zero-copy sniffer. Reincarnation #1. Numbers.

2005-07-29 Thread Max Krasnyansky
Evgeniy Polyakov wrote: 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 w

Re: [RFC] Zero-copy sniffer. Reincarnation #1. Numbers.

2005-07-29 Thread Evgeniy Polyakov
On Fri, Jul 29, 2005 at 09:41:09AM -0600, Christopher Friesen ([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(). > > Presumably as packet size decreases, at some poin

Re: [RFC] Zero-copy sniffer. Reincarnation #1. Numbers.

2005-07-29 Thread Evgeniy Polyakov
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 any

Re: [RFC] Zero-copy sniffer. Reincarnation #1. Numbers.

2005-07-29 Thread Max Krasnyansky
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 n

Re: [RFC] Zero-copy sniffer. Reincarnation #1. Numbers.

2005-07-29 Thread Christopher Friesen
Evgeniy Polyakov wrote: Couple of numbers... Remapping of the physical page took about 25-50% less time than 1500 bytes copying using memcpy(). Presumably as packet size decreases, at some point the memcpy() becomes cheaper. With your hardware, where is this crossover point? Chris - To unsu

[RFC] Zero-copy sniffer. Reincarnation #1. Numbers.

2005-07-29 Thread Evgeniy Polyakov
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(T