On Monday 20 April 2009 09:47:37 Kip Macy wrote: > On Mon, Apr 20, 2009 at 12:29 AM, Marko Zec <z...@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 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
