svn commit: r191259 - head/sys/netinet

[Marko Zec]

On Monday 20 April 2009 09:47:37 Kip Macy wrote:
> 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.

Hmm, such a scheme raises suspicion that in your particular case very few flow 
cache lookups could be serviced from CPU caches. 16MB + 80MB sounds to be in 
range with memory footprint of a DFZ table stored in our normal radix tree - 
so where's the benefit of the flow cache?

Marko

> 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