Date: Mon, 20 Apr 2009 10:04:19 +0200 From: Marko Zec <zec@freebsd.org> To: Kip Macy <kmacy@freebsd.org> Cc: svn-src-head@freebsd.org, Robert Watson <rwatson@freebsd.org>, svn-src-all@freebsd.org, src-committers@freebsd.org, Andre Oppermann <andre@freebsd.org> Subject: Re: svn commit: r191259 - head/sys/netinet Message-ID: <200904201004.19695.zec@freebsd.org> In-Reply-To: <3c1674c90904200047s551a93a3wec97607b8212b0d@mail.gmail.com> References: <200904190444.n3J4i5wF098362@svn.freebsd.org> <200904200929.57914.zec@freebsd.org> <3c1674c90904200047s551a93a3wec97607b8212b0d@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 20 April 2009 09:47:37 Kip Macy wrote: > On Mon, Apr 20, 2009 at 12:29 AM, Marko Zec <zec@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 awa= re > > of any current vendor who would use (T)CAMs indexed by a flow hash for > > routing lookups. =A0Wouldn't it be a more common case for a TCAM to hol= d a > > FIB table, sorted in a way which lets more specific prefixes having > > precedence? > > > > i.e. > > > > FIB =A0 =A0 =A0 =A0 =A0 =A0TCAM > > 10.0.1.0/24 -> 00001010 00000000 00000001 XXXXXXXX -> output port X > > 10.0.0.0/8 =A0-> 00001010 XXXXXXXX XXXXXXXX XXXXXXXX -> output port Y > > 0.0.0.0/0 =A0 -> 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 f= low=20 cache lookups could be serviced from CPU caches. 16MB + 80MB sounds to be i= n=20 range with memory footprint of a DFZ table stored in our normal radix tree = =2D=20 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200904201004.19695.zec>