Re: FreeBSD handles leapsecond correctly

:
: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_at_backplane.com>