tcp hostcache and ip fastforward for review

[Andre Oppermann]

popsong old wrote:
> 
> > ip_fastforward
> 
> >  - removes ip_flow forwarding code
> >  - adds full direct process-to-completion IPv4
> forwarding code
> >  - handles ip fragmentation incl. hw support
> (ip_flow did not)
> >  - supports ipfw and ipfilter (ip_flow did not)
> >  - supports divert and ipfw fwd (ip_flow did not)
> >  - drops anything it can't handle back to normal
> ip_input
> 
> Should we worry about the locking in IPFilter? It
> seems that there are no locking at all in IPFilter for
> FreeBSD.

I haven't touched ipfilter, but yes, there is currently no
locking in ipfilter. This ain't good I suppose. I guess it
would be easy to slap a global ipfilter lock on there. We
can't go directly into ipfilter to do locking because that
would take ipfilter off the vendor branch and would make
updating it impossible.

> 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