Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 8 Jan 2006 14:33:22 +0100
From:      Daniel Gerzo <danger@rulez.sk>
To:        Andre Oppermann <andre@freebsd.org>
Cc:        current@freebsd.org
Subject:   Re: Patch for 1mpps on if_em (was: FreeBSD handles leapsecondcorrectly)
Message-ID:  <20060108133322.GA39105@daemon.rulez.sk>
In-Reply-To: <43C0F89B.7FC19C0F@freebsd.org>
References:  <73774.1136109554@critter.freebsd.dk> <20060101035958.A86264@xorpc.icir.org> <43B7E1EC.5090301@mac.com> <200601060636.k066aNYn079015@apollo.backplane.com> <43BFEB2E.4040303@freebsd.org> <200601071940.k07JeHt3095158@apollo.backplane.com> <43C02362.2070009@samsco.org> <1136717948.4312.5.camel@massimo.datacode.it> <43C0F89B.7FC19C0F@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 08, 2006 at 12:33:47PM +0100, Andre Oppermann wrote:
> Massimo Lusetti wrote:
> > 
> > On Sat, 2006-01-07 at 13:24 -0700, Scott Long wrote:
> > 
> > > I'm about to release a patch to Andre that should allow if_em to fast
> > > forward 1mpps or more on his hardware, using no shortcuts or hacks other
> > > than the inherent shortcut that the ffwd code provides.  The approach
> > > I'm taking also works on the other high performance network interfaces.
> > > There is also a lot of work going on to streamline the ifnet layer that
> > > will likely result in several hundred nanoseconds of latency being
> > > removed from there.  I'd personally love to see DragonFly approach this
> > 
> > Will all this great stuff end up in RELENG_6 branch?
> 
> Some of it but not all.  Those things which are driver optimizations and
> other detail stuff will be backported.  Stuff that does architectual and
> API/ABI changes will not.  We are not allowed to break the API/ABI within
> a -STABLE series.
> 

are these things related to your TCP/IP Cleanup and Optimizations work?
if so, does it mean that you are going to merge this work to current
soon?

> > That's very good news (TM) to hear...
> 
> Indeed.  I have tons of measurements and data from the test runs which has
> to be processed.  Once that is done we can start to reach firm conclusions
> and to tackle all the other items which put some breaks on the performance.
> 
> -- 
> Andre

-- 
Daniel



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060108133322.GA39105>