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
On Fri, Jul 15, 2005 at 04:16:17PM -0700, Max Krasnyansky ([EMAIL PROTECTED])
wrote:
> Evgeniy,
>
> > The latest version is available at
> > http://tservice.net.ru/~s0mbre/archive/af_tlb
> >
> > It has several enhancements, fixed some stuff,
> > many cleanups. Fixed/upgraded skb freeing mechan
Evgeniy,
The latest version is available at
http://tservice.net.ru/~s0mbre/archive/af_tlb
It has several enhancements, fixed some stuff,
many cleanups. Fixed/upgraded skb freeing mechanism.
Thanks. I'll take a look at it.
I think this zero-copy mechanism
can be used in tun/tap devices too
On Fri, Jul 15, 2005 at 03:48:44PM -0700, Max Krasnyansky ([EMAIL PROTECTED])
wrote:
> Jamal,
>
> Thanx for forwarding. Somehow I didn't see this one. I guess it's time for me
> to check my linux-kernel and netdev subscriptions :).
>
> >>Basic idea behind zero-copy is remapping of the
> >>physi
Jamal,
Thanx for forwarding. Somehow I didn't see this one. I guess it's time for me
to check my linux-kernel and netdev subscriptions :).
Basic idea behind zero-copy is remapping of the
physical pages where skb->data lives to the
userspace process.
According to my tests, which can be found c
On Fri, Jul 15, 2005 at 05:51:41PM -0400, Jamal Hadi Salim ([EMAIL PROTECTED])
wrote:
> Evgeniy,
>
> Some good ideas in there.
> You should talk/sync to Max Krasnyansky (CCed). I think theres a lot of
> stuff you are doing that he is trying to do as well with the new tuntap
> that he is working
Evgeniy,
Some good ideas in there.
You should talk/sync to Max Krasnyansky (CCed). I think theres a lot of
stuff you are doing that he is trying to do as well with the new tuntap
that he is working on. I think put together - some cool ideas can be
implemented.
cheers,
jamal
On Thu, 2005-14-07
Hello, network developers.
I'm pleased to announce first pre-alpha version
of the Zero-copy sniffer "device".
It acts as packet socket, i.e. gets all packets
using prot_hook.func(), but never copy it.
Basic idea behind zero-copy is remapping of the
physical pages where skb->data lives to the
us
19 matches
Mail list logo
