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@xxxxxxxxxxxxx>
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: What is involved in switching from i386 to AMD64?
    ... facing a motherboard/CPU upgrade following the demise of an Athlon+ ... happens if I were to put the FreeBSD i386 HD into a 64-bit system. ... Since the AMD64 architecture is completely backwards-compatible with the ...
    (freebsd-questions)
  • Selecting CPU/architecture for new system?
    ... I'm currently in the process of selecting hardware for a FreeBSD ... system having the main task of collecting network statistics via MRTG ... either 32- or 64-bit architecture. ... o) Are SMP-systems with 4 CPUs supported in i386? ...
    (freebsd-questions)
  • Re: amd64 ?!
    ... i did ask for an intel machine and the dmseg actually states: ... "amd64" is the name FreeBSD uses for the 64-bit architecture built ...
    (freebsd-questions)
  • Re: Does the AMD64 version of FreeBSD run on this?
    ... >>architecture, etc), they are committed to maintain compatibility between ... Has anyone tested the AMD64 version of FreeBSD ...
    (freebsd-questions)