Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 06 May 2008 14:08:30 -0700
From:      Julian Elischer <julian@elischer.org>
To:        "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
Cc:        FreeBSD Net <freebsd-net@freebsd.org>
Subject:   Re: multiple routing tables review patch ready for simple testing.
Message-ID:  <4820C8CE.8010309@elischer.org>
In-Reply-To: <20080506202940.K47338@maildrop.int.zabbadoz.net>
References:  <4816D1D2.7010603@elischer.org> <20080506202940.K47338@maildrop.int.zabbadoz.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Bjoern A. Zeeb wrote:
> On Tue, 29 Apr 2008, Julian Elischer wrote:
> 
> Hi,
> 
>> The patch can be found at
>> http://www.freebsd.org/~julian/mrt.diff
>> (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6)
>>
>> or source can be taken from perforce at:
>> //depot/user/julian/routing/src
> 
> So after looking at the patch a bit more again, could you add wrapper
> functions for those like you have done for the old KPI (rtrequest, 
> rtrequest1,

do you really want to do the extra work instructions?

> ..)?
> 
> + * For now the protocol indepedent versions are the same as the AF_INET 
> ones
> + * but this will change.. just #define them at this time.
> + */
> +#define        in_rt_getifa(_a, _b)            rt_getifa_fib(_a, _b)
> +#define        in_rtalloc_ign(_a, _b, _c)      rtalloc_ign_fib(_a, _b, _c)
> +#define        in_rtalloc(_a, _b)              rtalloc_fib(_a, _b)
> +#define in_rtalloc1(_a, _b, _c, _d)    rtalloc1_fib(_a, _b, _c, _d)
> +#define        in_rtioctl(_a, _b, _c)          rtioctl_fib(_a, _b, _c)
> +#define        in_rtredirect(_a, _b, _c, _d, _e, _f) \
> +                                       rtredirect_fib(_a, _b, _c, _d, 
> _e, _f)
> +#define         in_rtrequest(_a, _b, _c, _d, _e, _f, _g) \
> +                                       rtrequest_fib(_a, _b, _c, _d, 
> _e, _f,_g)
> +#define         in_rtrequest1(_a, _b, _c, _d)  rtrequest1_fib(_a, _b, 
> _c, _d)
> +#define         in_rt_check(_a, _b, _c, _d)    rt_check_fib(_a, _b, _c, 
> _d)
> 
> 
> The defines will not give you a stable KPI and having that changed again
> if you are going with a prefix for each AF would be a pain if the _fib 
> versions
> are going to change in the future.

hmm fair enough... but let me outline my plans and thoughts
so we can see if you still want this..

In order to get away from having every protocol (existing or not)
from preallocating N fib heads (currently it is done in protocol
independent code) the protocols themselves need to know if they are
allocating multiple FIBS and how many. For this reason,
the protocol versions will eventually know where their own
fibs are stored and act on them as needed, allowing them to be 
dynamically allocated. (as many as needed).
The methods for each protocol family woudl be pointed to in the
domain structure, and the protocol independent versions would look 
them up that way and call them..


so the domain structure would include:

struct domain {
     [...]
     *(struct rtentry *dom_rtalloc)(mumble);
     [...]
};
(or whatever the syntax is (I always have to look it up)

in netinet we would declare

struct domain inet_domain = {
      [...]
      in_rtalloc,
      [...]
];

A new function find_domain(family)
makes a method independent way to find the domain structure for
any given PF/AF.

So rtalloc_fib would be:

struct rtentry *
rtalloc_fib( struct route *ro, int fib)
{
    struct domain *dp;
    dp = find_domain(ro->ro_dst.sa_family)
    if (dp)
        return (*(dp->dom_rtalloc)(ro, fib));
    return (NULL);
}

This all however is not ABI compatible so could not go back to 7.x
and I want to check in an initial version that can go back to 7.x
which sort of suggests to me that adding in_xxx functions is
not really required, until I do the next step.
7.x will never get the next step. because the ABI is already set
in stone for 7.x.

I would make the in_xxx stubs in the next step in 8.x.
after the MFC to 7.x of the ABI compat version.


let me know what you think.








Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4820C8CE.8010309>