On Thu, Oct 14, 2004 at 09:42:25PM +0400, Gleb Smirnoff wrote:
> any objections about commiting this improvement to tun(4)?
Optimal use of mbuf clusters to improve performance is cool.
Please consider committing this once reworked to use m_uiotombuf.
BMS
On Thu, Oct 14, 2004 at 04:23:42PM -0700, Julian Elischer wrote:
J> yes I know, that's how we wrote divert.. (to be independent) netgraph
J> came later..
J> I guess we would have done divert differently if we had done netgraph
J> first..
J> probably would have given ipfw a "hook" command that se
On Thu, Oct 14, 2004 at 10:48:32PM +0200, Andre Oppermann wrote:
A> > We are going to have triple cut'n'paste: if_tun.c, ng_device.c, if_tap.c.
A> > What about m_uiocopy()? The question is where can we put this function?
A>
A> What about the existing m_uiotombuf() function in kern/uipc_mbuf.c?
Da
Andre Oppermann wrote:
Julian Elischer wrote:
Andre Oppermann wrote:
P.S. I'm working on making protocols within protocols domains loadable at
least for IPv4.
I did some work on this once.. things have got a lot more complicated
however with locking..
Actually there are not tha
Julian Elischer wrote:
>
> Andre Oppermann wrote:
> >
> >P.S. I'm working on making protocols within protocols domains loadable at
> >least for IPv4.
> >
> I did some work on this once.. things have got a lot more complicated
> however with locking..
Actually there are not that many locking probl
Andre Oppermann wrote:
Gleb Smirnoff wrote:
On Thu, Oct 14, 2004 at 08:01:46PM +0200, Andre Oppermann wrote:
A> > any objections about commiting this improvement to tun(4)?
A> > In my ng_device I have a similar function ngdwrite(), which was
A> > cut-n-pasted from tunwrite(). And my tests wit
Gleb Smirnoff wrote:
>
> On Thu, Oct 14, 2004 at 08:01:46PM +0200, Andre Oppermann wrote:
> A> > any objections about commiting this improvement to tun(4)?
> A> > In my ng_device I have a similar function ngdwrite(), which was
> A> > cut-n-pasted from tunwrite(). And my tests with a patched ng_d
On Thu, Oct 14, 2004 at 08:01:46PM +0200, Andre Oppermann wrote:
A> > any objections about commiting this improvement to tun(4)?
A> > In my ng_device I have a similar function ngdwrite(), which was
A> > cut-n-pasted from tunwrite(). And my tests with a patched ng_device have
A> > shown 30% speedu
Gleb Smirnoff wrote:
>
> Collegues,
>
> any objections about commiting this improvement to tun(4)?
> In my ng_device I have a similar function ngdwrite(), which was
> cut-n-pasted from tunwrite(). And my tests with a patched ng_device have
> shown 30% speedup on large writes. I don't think it
Gleb Smirnoff wrote:
>
> Collegues,
>
> any objections about commiting this improvement to tun(4)?
> In my ng_device I have a similar function ngdwrite(), which was
> cut-n-pasted from tunwrite(). And my tests with a patched ng_device have
> shown 30% speedup on large writes. I don't think it
Collegues,
any objections about commiting this improvement to tun(4)?
In my ng_device I have a similar function ngdwrite(), which was
cut-n-pasted from tunwrite(). And my tests with a patched ng_device have
shown 30% speedup on large writes. I don't think it will help tun(4)
to be a much faste
11 matches
Mail list logo
