Date: Sat, 02 May 1998 00:47:38 -0500 From: Chris Csanady <ccsanady@friley585.res.iastate.edu> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: freebsd-net@FreeBSD.ORG, jtw@lcs.mit.edu Subject: Re: Fast IP forwarding Message-ID: <199805020547.AAA04760@friley585.res.iastate.edu> In-Reply-To: Your message of "Sat, 02 May 1998 00:32:47 EDT." <199805020432.AAA10671@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
><<On Fri, 01 May 1998 21:29:37 -0500, Chris Csanady <ccsanady@friley585.res.ia state.edu> said: > >> I have included the ip_input() function from Van Jacobsons experimental >> stack as a reference. It uses an extremely simple cache, that requires >> little memory and only a handful of instructions that manage it. This >> code should actually have *very* low overhead even in the common case. > >Wow, that's a but more complicated than I would have expected from >Van. Here's a slightly different take on the same concept... with Really? I actually thought it quite simple. It looks as though this input routine is functionally identical, although with different syntax and a few more features. >some comments from eighteen months after the fact. (Some wild >mutation of this may have eventually made it into the CAIRN group's >sources---JTW certainly did have a copy of it when I left the fifth >floor.) Note that, in a real router, you probably don't want to use a >cache at all, but rather a specialized data structure that can >compactly store the entire routing table and access it directly with a >minimum of instructions. Or at least that's what I last heard, >anyway. A couple of papers on such data structures were presented at >the last SIGCOMM. Are you referring to the LC-trie, or something else? The LC-trie looks quite interesting. There is a bit of information on it here in case anyone gets ambitious.. http://www.cs.hut.fi/~sni/papers/router/router.html As usual, the mbuf handling is disgusting. I'm not sure I like the VHL marcos a lot either. It seems like it would be easier to read if it was just a union containing ip_vhl, and (ip_v, ip_hl). That really does not matter though I suppose. I am kindof curious though, would filling the cache in the fast path be slower than actually taking the slow path? In Van's code, the cache route entry is set to 0 for local destinations. After it is filled, no local dests would require lookups. I must say, I find the action member quite interesting. Is there a place where I can find out more about these non-standard gcc things? Regardless, I find this looks quite nice. If this is a finished work, is there any reason why it could not be integrated? -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805020547.AAA04760>