Date: Sat, 7 Jan 2006 12:40:55 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Scott Long <scottl@samsco.org> Cc: Andre Oppermann <andre@freebsd.org>, current@freebsd.org Subject: Re: FreeBSD handles leapsecond correctly Message-ID: <200601072040.k07KetMR095625@apollo.backplane.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:Matthew Dillon 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
:level of performance. Given that it took FreeBSD about 3-4 years to
:slog through setting up and validating a new architecture before we
:could start focusing on performance, I think that DFly is right on track
:on the same schedule. Hopefully the results are as worthwhile on DFly
:in the future as they are on FreeBSD right now.
:
:Scott
I think it's very possible. We have taken pains to retain the
fast-forwarding architecture (i.e. direct lookups, no context switches,
handle everything in the interrupt) and to greatly reduce mbuf allocation
overheads (e.g. by using Jeff's objcache infrastructure, which is an
algorithmic port of Sun's objcache infrastructure).
There are three areas of interest for us in this architecutre:
(1) Route table lookups. This is basically a non-problem because Jeff
already has a per-cpu route table replication patch that will allow
us to do route table lookups without having to obtain or release
any locks or perform any bus locked instructions.
(2) Per-interface serializer (mutex). Right now the core packet
processing loop must release the originating interface serializer
and obtain the target interface serializer to forward a packet,
then release the target and re-obtain the originating. Clearly
this can be cleaned up by aggregating packets processed by the
originating interface and only doing the swap-a-roo once for N
packets.
The current code is a migratory 'hack' until the whole network
subsystem can be moved to the new network interface serializer.
Right now only the network interrupt subsystem has been moved to
the new serializer, so networking code is holding both the MP lock
AND the serializer.
(3) The IP filter / firewall code is the last big item we are going to
have a problem with. I intend to remove at least one of the packet
filters we support and do per-cpu replication for the remainder.
It turns out that most of the packet filter can be replicated, even
dynamically generated rules and queues and such. But its a lot of
work.
-Matt
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200601072040.k07KetMR095625>