Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink

[jamal <hadi@cyberus.ca>]

On Fri, 2005-27-05 at 18:35 +0200, Thomas Graf wrote:

> I do NOT agree on moving gc_ into this architecture as well,
> it doesn't belong there.

Well, you do realize they are part of the in_dev ? ;->

> Nitpicking for a bit, although inet6_dev and in_device hold
> reference to the their arp respectively ndisc parameter set,
> the sysctl interface does not use this reference but stores
> the ifindex of the netdevice, _which_ is correct I think
> because parameter sets are _not_ limited to inetdevs in terms
> of architecture but only in terms of current use.
> 

I see a little main service header with ifindex always no different than
IFA or IFLINK etc followed by appropriate TLVs which are nested.

Unfortunately i still cant find the patch - i started with a different
approach; my immediate interest was to get events when someone made 
in_device changes. BTW, this is going to be one of the main challenges
since there are many paths to configure these things.

> > The deafult can be overriden by devX. So they dont need to sync.
> > But this is a separate topic
> 
> I was not talking about in-sync but rather that gc_* only
> appears in default/ but not in devX/. What I expect is that
> every default parameter can be overwritten in devX which
> is not true for gc_*. Which is the reason why I implemented
> them outside of the NDTPA_PARMS nested TLV.
> 

Well, if you look at the structure there is no reason they should really
be separate; infact theres a comment:
-----------
         struct neigh_parms      parms;
        /* HACK. gc_* shoul follow parms without a gap! */
        int                     gc_interval;
        int                     gc_thresh1;
        int                     gc_thresh2;
----------

To me the abstraction is pretty clear. I would agree that the way
parameters configurable from user space and some of the methods may not
be the best in terms of neighbor tables organization.


> I understand your architecture and if we follow this thought
> we'd have a "default" netdevice which repesents all default
> settings. 

>From looking at the code, the default stuff seems to be "hardcoded".
Example in the definition arp_tbl.

> I do agree with this architecture but the problematic
> question remains: Do we want parameters in "default" which are
> not available in devX? I think this question is what it gets
> down to in the end. If we say, yes we do want this, then we
> can implement all generic settings, such as tcp_, using this
> scheme as well. I don't disagree with this completely but I
> find it not very intuitive from a user perspective.

The model like i said is clean. There are some issues i have qualms with
- such as IP address arrangements and tight integration with netdevices
- but those can addressed at a later time.

cheers,
jamal