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
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_
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
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
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
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
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
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
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
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
On Thu, Jul 28, 2005 at 12:44:41PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> Hello, developers.
>
> This cruft works now much better.
> Unfortunately I need to add some scary PTE insults- you can find them in
> update_address().
> One big nitpick is that this module can not be unloaded
Hello, developers.
This cruft works now much better.
Unfortunately I need to add some scary PTE insults- you can find them in
update_address().
One big nitpick is that this module can not be unloaded if application
do not closes socket - socket is being removed after mapping is destroyed,
so I n
12 matches
Mail list logo
