[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-tech
Subject:    Re: testers needed to finish multiple routing tables
From:       Henning Brauer <lists-openbsdtech () bsws ! de>
Date:       2006-10-27 16:06:48
Message-ID: 20061027160648.GN22157 () nudo ! bsws ! de
[Download RAW message or body]

* Henning Brauer <henning@openbsd.org> [2006-10-27 17:34]:
> * Claudio Jeker <claudio@openbsd.org> [2006-10-27 17:13]:
> > > +int	ipforward_rtableid;
> > GROSS! Can't we finaly kill this stupid ipforward_rt cached route?
> > Especially now that multiple tables come into play. I assume that you can
> > not see a difference in performance with or without it. 
> I am not certain about the performance impact; no matter what I am a 
> strongly believe that seperate issues should be dealt with seperately, 
> so either we kill that beforehands or afterwards, but do not sneak that 
> with this diff.

let me make this clear, since my diff adds ipforward_rtableid, which 
looks a bit like a cache:

right now, there is a cache for the last used route, ipforward_rt. If 
we remove _that_ beforehands, ipforward_rtableid is not necessary. 
If we leave ipforward_rt and do not add ipforward_rtableid, we might use 
the cache incorrectly (using a route with the same destination from 
another table).
The check for the cache, with my diff, is:

        if ((rt = ipforward_rt.ro_rt) == 0 ||
            ip->ip_dst.s_addr != sin->sin_addr.s_addr || 
            rtableid != ipforward_rtableid) {

where ipforward_rt is global
struct  route ipforward_rt;

ipforward_rtableid is NOT a cache to speed things up, it is just there 
to make sure we do not use the existing ipforward_rt cache incorrectly.

[prev in list] [next in list] [prev in thread] [next in thread]