tcp hostcache and ip fastforward for review
oppermann at pipeline.ch
Wed Nov 12 02:36:31 PST 2003
popsong old wrote:
> --- Andre Oppermann <oppermann at pipeline.ch> wrote:
> > > BTW, we'll get even better performance if we keep both
> > > interfaces' MAC addresses in cache (and call
> > > ifp->if_start directly). This requires to keep
> > > ethernet header in mbuf untouched and is only relevant
> > > in ethernet though. I implemented such layer 2 cache
> > > in a local version of IPFilter and got some good
> > > results.
> > I don't understand why you want to do that unless you
> > are doing bridging. We have to look up the mac address
> > of the next hop anyway. If that is not already in the
> > routing table it needs to do a arp lookup.
> > --
> > Andre
> Ah, my fault. I didn't read your patch carefully and assumed that ip
> fastforward do flow caching as ip_flow does. However, I think ip flow
> caching is a good thing and maybe implementing it in ip fastforward is
> a good idea.
Please explain why flowcaching is good. Cisco did away with it
quite some time ago because it didn't scale at all. Plus it is
very complex in the context of the BSD network stack.
For IP fastforward we look at one thing, that is the destination IP
address. In a flow cache we need look at the destination IP address
and the destination host. Then we have to make a hash based cache
of size n. Problem number one: Is it really faster to look into the
hash table than the routing table? Problem number two: Is there any
caching effect at all in the hash table? Answer number one: No, it
is not faster on today's hardware. And if we don't find it in the
hash table we have to do the routing table lookup anyway. Answer
number two: Unless you have only a couple of flows the hit rate is
very low. If you have a couple of flows only then the routing table
stays in L1/2 cache of the CPU anyway as does the routing table. No
gain there. With too many flows you simply start thrashing the hash
table for no benefit.
More information about the freebsd-net