From owner-svn-src-all@FreeBSD.ORG Mon Apr 20 08:04:31 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DC73106566B; Mon, 20 Apr 2009 08:04:31 +0000 (UTC) (envelope-from zec@freebsd.org) Received: from labs4.cc.fer.hr (labs4.cc.fer.hr [161.53.72.24]) by mx1.freebsd.org (Postfix) with ESMTP id C98CE8FC14; Mon, 20 Apr 2009 08:04:30 +0000 (UTC) (envelope-from zec@freebsd.org) Received: from sluga.fer.hr (sluga.cc.fer.hr [161.53.72.14]) by labs4.cc.fer.hr (8.14.2/8.14.2) with ESMTP id n3K84j98026053; Mon, 20 Apr 2009 10:04:45 +0200 (CEST) Received: from [192.168.200.110] ([161.53.19.79]) by sluga.fer.hr over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 10:04:23 +0200 From: Marko Zec To: Kip Macy Date: Mon, 20 Apr 2009 10:04:19 +0200 User-Agent: KMail/1.9.10 References: <200904190444.n3J4i5wF098362@svn.freebsd.org> <200904200929.57914.zec@freebsd.org> <3c1674c90904200047s551a93a3wec97607b8212b0d@mail.gmail.com> In-Reply-To: <3c1674c90904200047s551a93a3wec97607b8212b0d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200904201004.19695.zec@freebsd.org> X-OriginalArrivalTime: 20 Apr 2009 08:04:23.0498 (UTC) FILETIME=[9DDFDAA0:01C9C18E] X-Scanned-By: MIMEDefang 2.64 on 161.53.72.24 Cc: svn-src-head@freebsd.org, Robert Watson , svn-src-all@freebsd.org, src-committers@freebsd.org, Andre Oppermann Subject: Re: svn commit: r191259 - head/sys/netinet X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 08:04:32 -0000 On Monday 20 April 2009 09:47:37 Kip Macy wrote: > On Mon, Apr 20, 2009 at 12:29 AM, Marko Zec 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