svn commit: r191259 - head/sys/netinet

[Kip Macy]

On Mon, Apr 20, 2009 at 12:29 AM, Marko Zec <zec at freebsd.org> wrote:
> On Monday 20 April 2009 09:01:25 Kip Macy wrote:
> ...
>> > But it seems to me that CAM lookups are pretty resilient against DoSing
>> > by throwing malicious synthetic flows on them, whereas flow caches will
>> > melt down easily.
>>
>> Actually a CAM is a hardware implementation of a hash table. It has
>> the same limitations. To claim that routers don't use flow tables
>> because they are handled in hardware is a very strange thing to say.
>
> Well I may be missing something, but TCAMs typically used for routing lookups
> are populated by the router's control plane, i.e. routing protocols, which
> means that the number of entries in the FIB / TCAM correlates to the size of
> RIB, i.e. it definitely doesn't grow / shrink dynamically in response to the
> current flow pattern.
>
> And I may not know how CAMs are implemented internally, but I'm not aware of
> any current vendor who would use (T)CAMs indexed by a flow hash for routing
> lookups.  Wouldn't it be a more common case for a TCAM to hold a FIB table,
> sorted in a way which lets more specific prefixes having precedence?
>
> i.e.
>
> FIB            TCAM
> 10.0.1.0/24 -> 00001010 00000000 00000001 XXXXXXXX -> output port X
> 10.0.0.0/8  -> 00001010 XXXXXXXX XXXXXXXX XXXXXXXX -> output port Y
> 0.0.0.0/0   -> XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX -> output port Z
>
> This definitely doesn't change with flows dynamics IMO.

I'm not saying they're the same thing. I'm saying conceptually they're
equivalent.

The main point I'm getting at is that if your working set exceeds the
size of your cache (whatever you are caching) your performance will be
poor - period. Even after a number optimizations, FreeBSD is not
likely to be able to forward more than 500kpps per core in the near
future (i.e. 4Mpps on an 8-core). In the somewhat extreme case (from
the environments I'm familiar with), you have 1 million unique
destination IPs (per core) within a 30 second window - or 1 packet to
each destination every other second, a 2 million entry table would
require 16MB + ~80MB for the flows themselves (per core). A large
amount of memory certainly, but nothing extraordinary when my laptop
contains more than twice that.

I'm not saying that cases where there is no locality in the
destination space or that they aren't important use cases. I'm just
saying that they're very much in the minority and those users can
either disable the flowtable or 'nooption' it in their config.


-Kip