[RFC] neighbour tables configuration via rtnetlink

[RFC] neighbour tables configuration via rtnetlink

[Thomas Graf]

Hi,

I have need to change multiple neighbour table parameters as a atomic operation
which lead me to make it available via rtnetlink. I started with the patch
below which extends the existing RTM_*NEIGH commands by a flag NTF_TABLES
changing the context from entries to the tables itself. I regard this as quite
hacky, the alternative would be to add a new RTM operation set, i.e.
RTM_*NEIGHTBL or alike.

It's only dumping for now but I plan to also allow modification of parameters.
One of the problem that arises is the fact that the interface identifier,
to differ the various parameters sets, is stored in the sysctl table which
would introduce quite a nasty depedency.

Before I go ahead, putting more effort into it, what is our preferred
interface for network configuration? My personal preference is to make
everything available via netlink with the long term plan to extend it
with distributive remote configuration protocol in userspace. If so,
shall we continue to push everything into rtnetlink regardless of the
association to routing? The only drawback of the currently "overloaded"
rtnetlink is the rtnl semaphore which has grown into something like
the BKL for networking. I'm not aware of any performance problems or
other issues because of this except for the module loading over nfs.
Does anyone?

Thoughts?


diff -Nru linux-2.6.11-rc3-bk3.orig/include/linux/rtnetlink.h linux-2.6.11-rc3-bk3/include/linux/rtnetlink.h
--- linux-2.6.11-rc3-bk3.orig/include/linux/rtnetlink.h	2005-02-11 04:04:22.000000000 +0100
+++ linux-2.6.11-rc3-bk3/include/linux/rtnetlink.h	2005-02-11 02:02:52.000000000 +0100
@@ -459,6 +459,7 @@
  *	Neighbor Cache Entry Flags
  */
 
+#define NTF_TABLES	0x01	/* Dump neighbour tables */
 #define NTF_PROXY	0x08	/* == ATF_PUBL */
 #define NTF_ROUTER	0x80
 
@@ -487,6 +488,71 @@
 	__u32		ndm_refcnt;
 };
 
+enum {
+	NDTA_UNSPEC,
+	NDTA_TABLE,
+	NDTA_PARAMS,
+	NDTA_STATS,
+	__NDTA_MAX
+};
+#define NDTA_MAX (__NDTA_MAX - 1)
+
+/*****
+ * Neighbour Tables Access
+ *****/
+
+struct nd_table_stats
+{
+	__u64		ndts_allocs;
+	__u64		ndts_destroys;
+	__u64		ndts_hash_grows;
+	__u64		ndts_res_failed;
+	__u64		ndts_lookups;
+	__u64		ndts_hits;
+	__u64		ndts_rcv_probes_mcast;
+	__u64		ndts_rcv_probes_ucast;
+	__u64		ndts_periodic_gc_runs;
+	__u64		ndts_forced_gc_runs;
+};
+
+struct ndt_params
+{
+	__u32		ndtp_refcnt;
+	__u32		ndtp_base_reachable_time;
+	__u32		ndtp_reachable_time;
+	__u32		ndtp_retrans_time;
+	__u32		ndtp_gc_staletime;
+	__u32		ndtp_delay_probe_time;
+	__u32		ndtp_queue_len;
+	__u32		ndtp_app_probes;
+	__u32		ndtp_ucast_probes;
+	__u32		ndtp_mcast_probes;
+	__u32		ndtp_anycast_delay;
+	__u32		ndtp_proxy_delay;
+	__u32		ndtp_proxy_qlen;
+	__u32		ndtp_locktime;
+};
+
+#define NDT_TBLNAMSIZ 16
+
+struct nd_table
+{
+	char		ndt_id[NDT_TBLNAMSIZ];
+	__u16		ndt_key_len;
+	__u16		ndt_entry_size;
+	__u16		ndt_gc_interval;
+	__u16		ndt_gc_thresh1;
+	__u16		ndt_gc_thresh2;
+	__u16		ndt_gc_thresh3;
+	__u32		ndt_entries;
+	__u32		ndt_last_flush;
+	__u32		ndt_last_rand;
+	__u32		ndt_hash_rnd;
+	__u32		ndt_hash_mask;
+	__u32		ndt_hash_chain_gc;
+	__u32		ndt_proxy_qlen;
+};
+
 /****
  *		General form of address family dependent message.
  ****/
diff -Nru linux-2.6.11-rc3-bk3.orig/net/core/neighbour.c linux-2.6.11-rc3-bk3/net/core/neighbour.c
--- linux-2.6.11-rc3-bk3.orig/net/core/neighbour.c	2005-02-11 04:04:22.000000000 +0100
+++ linux-2.6.11-rc3-bk3/net/core/neighbour.c	2005-02-11 02:00:26.000000000 +0100
@@ -1623,13 +1623,109 @@
 	return rc;
 }
 
+static int neigh_dump_table_meta(struct neigh_table *tbl, struct sk_buff *skb,
+				 struct netlink_callback *cb)
+{
+	int i, locked = 0;
+	unsigned char *b = skb->tail;
+	struct nd_table ndtbl;
+	struct nd_table_stats st;
+	struct neigh_parms *p;
+	struct rtattr *rta;
+	int pid = NETLINK_CB(cb->skb).pid;
+	struct nlmsghdr *nlh = NLMSG_PUT(skb, pid, cb->nlh->nlmsg_seq,
+					 RTM_NEWNEIGH, sizeof(struct ndmsg));
+	struct ndmsg *ndm = NLMSG_DATA(nlh);
+
+	nlh->nlmsg_flags = pid ? NLM_F_MULTI : 0;
+	ndm->ndm_flags	 = NTF_TABLES;
+	ndm->ndm_type	 = 0;
+	ndm->ndm_state	 = 0;
+	ndm->ndm_ifindex = 0;
+
+	read_lock_bh(&tbl->lock);
+	locked = 1;
+
+	ndm->ndm_family		= tbl->family;
+	ndtbl.ndt_key_len	= tbl->key_len;
+	ndtbl.ndt_entry_size	= tbl->entry_size;
+	ndtbl.ndt_gc_interval	= tbl->gc_interval;
+	ndtbl.ndt_gc_thresh1	= tbl->gc_thresh1;
+	ndtbl.ndt_gc_thresh1	= tbl->gc_thresh2;
+	ndtbl.ndt_gc_thresh1	= tbl->gc_thresh3;
+	ndtbl.ndt_entries	= atomic_read(&tbl->entries);
+	ndtbl.ndt_last_flush	= tbl->last_flush;
+	ndtbl.ndt_last_rand	= tbl->last_rand;
+	ndtbl.ndt_hash_rnd	= tbl->hash_rnd;
+	ndtbl.ndt_hash_mask	= tbl->hash_mask;
+	ndtbl.ndt_hash_chain_gc	= tbl->hash_chain_gc;
+	ndtbl.ndt_proxy_qlen	= tbl->proxy_queue.qlen;
+
+	strncpy(ndtbl.ndt_id, tbl->id, sizeof(ndtbl.ndt_id));
+	RTA_PUT(skb, NDTA_TABLE, sizeof(ndtbl), &ndtbl);
+
+	st.ndts_allocs		 = tbl->stats->allocs;
+	st.ndts_destroys	 = tbl->stats->destroys;
+	st.ndts_hash_grows	 = tbl->stats->hash_grows;
+	st.ndts_res_failed	 = tbl->stats->res_failed;
+	st.ndts_lookups		 = tbl->stats->lookups;
+	st.ndts_hits		 = tbl->stats->hits;
+	st.ndts_rcv_probes_mcast = tbl->stats->rcv_probes_mcast;
+	st.ndts_rcv_probes_ucast = tbl->stats->rcv_probes_ucast;
+	st.ndts_periodic_gc_runs = tbl->stats->periodic_gc_runs;
+	st.ndts_forced_gc_runs	 = tbl->stats->forced_gc_runs;
+	RTA_PUT(skb, NDTA_STATS, sizeof(st), &st);
+
+	rta = (struct rtattr *) skb->tail;
+	RTA_PUT(skb, NDTA_PARAMS, 0, NULL);
+
+	for (p = &tbl->parms, i = 1; p ; p = p->next, i++) {
+		struct ndt_params pa;
+
+		/* FIXME: ifindex from sysctl table should be included
+		 * here to allow userspace to differ each parameter set */
+
+		pa.ndtp_refcnt			= atomic_read(&p->refcnt);
+		pa.ndtp_base_reachable_time	= p->base_reachable_time;
+		pa.ndtp_reachable_time		= p->reachable_time;
+		pa.ndtp_retrans_time		= p->retrans_time;
+		pa.ndtp_gc_staletime		= p->gc_staletime;
+		pa.ndtp_delay_probe_time	= p->delay_probe_time;
+		pa.ndtp_queue_len		= p->queue_len;
+		pa.ndtp_app_probes		= p->app_probes;
+		pa.ndtp_ucast_probes		= p->ucast_probes;
+		pa.ndtp_mcast_probes		= p->mcast_probes;
+		pa.ndtp_anycast_delay		= p->anycast_delay;
+		pa.ndtp_proxy_delay		= p->proxy_delay;
+		pa.ndtp_proxy_qlen		= p->proxy_qlen;
+		pa.ndtp_locktime		= p->locktime;
+		RTA_PUT(skb, i, sizeof(pa), &pa);
+	}
+
+	rta->rta_len = (skb->tail - (unsigned char *) rta);
+
+	read_unlock_bh(&tbl->lock);
+	locked = 0;
+
+	nlh->nlmsg_len	 = skb->tail - b;
+	return skb->len;
+
+nlmsg_failure:
+rtattr_failure:
+	if (locked)
+		read_unlock_bh(&tbl->lock);
+	skb_trim(skb, b - skb->data);
+	return -1;
+}
+
 int neigh_dump_info(struct sk_buff *skb, struct netlink_callback *cb)
 {
 	struct neigh_table *tbl;
-	int t, family, s_t;
+	int t, family, s_t, flags;
 
 	read_lock(&neigh_tbl_lock);
 	family = ((struct rtgenmsg *)NLMSG_DATA(cb->nlh))->rtgen_family;
+	flags = ((struct ndmsg *)NLMSG_DATA(cb->nlh))->ndm_flags;
 	s_t = cb->args[0];
 
 	for (tbl = neigh_tables, t = 0; tbl; tbl = tbl->next, t++) {
@@ -1638,8 +1734,13 @@
 		if (t > s_t)
 			memset(&cb->args[1], 0, sizeof(cb->args) -
 						sizeof(cb->args[0]));
-		if (neigh_dump_table(tbl, skb, cb) < 0)
-			break;
+		if (flags & NTF_TABLES) {
+			if (neigh_dump_table_meta(tbl, skb, cb) < 0)
+				break;
+		} else {
+			if (neigh_dump_table(tbl, skb, cb) < 0)
+				break;
+		}
 	}
 	read_unlock(&neigh_tbl_lock);
 

Re: [RFC] neighbour tables configuration via rtnetlink

[jamal]

On Sat, 2005-03-05 at 12:22, Thomas Graf wrote:
> Hi,
> 
> I have need to change multiple neighbour table parameters as a atomic operation

The patch overall looks ok although adventerous.
What is it that requires you to change multiple parameters atomically? I
cant seem to think of anything. I can see value in seeing some of these
parameters in user space. Maybe.

> which lead me to make it available via rtnetlink. I started with the patch
> below which extends the existing RTM_*NEIGH commands by a flag NTF_TABLES
> changing the context from entries to the tables itself. I regard this as quite
> hacky, the alternative would be to add a new RTM operation set, i.e.
> RTM_*NEIGHTBL or alike.
> 
> It's only dumping for now but I plan to also allow modification of parameters.

Some of the parameters you are dumping maybe dangerous if they are also
allowed to be setable. As an example, changing a table name/id etc.
I think you should review closely again what needs to be exposed.

> One of the problem that arises is the fact that the interface identifier,
> to differ the various parameters sets, is stored in the sysctl table which
> would introduce quite a nasty depedency.
> 
> Before I go ahead, putting more effort into it, what is our preferred
> interface for network configuration? My personal preference is to make
> everything available via netlink 

I think this is reasonable. However - it is a lot of work. I will have
no issues with seeing nothing else but netlink (even for ethtool like
setups). There are certain things that would require more attention than
others. I was going to write a simple patch to allow setting of indev
parameters via netlink but havent had time. Started it but havent had
time to revisit it - if you want to take over that one as well i could
pass it on to you.

> with the long term plan to extend it with distributive remote configuration 
> protocol in userspace. 

Related but slightly different issues.
To achieve distributed configuration you dont need netlink. The main
advantage of netlink over say /proc is the ability to do async events.
[Yes, I know i have been shouting for taking netlink and and sending it
over the wire and mucking around with endianness flags - but after
practical considerations i am having second thoughts;] 

> If so,
> shall we continue to push everything into rtnetlink regardless of the
> association to routing? The only drawback of the currently "overloaded"
> rtnetlink is the rtnl semaphore which has grown into something like
> the BKL for networking. I'm not aware of any performance problems or
> other issues because of this except for the module loading over nfs.
> Does anyone?
> 

You need rtnetlink for anything that has "interface" relationship
because for those you end up using the rtnl semaphore. So you are stuck
for all the ones that somehow in their configuration the term "dev" may
appear.


cheers,
jamal

Re: [RFC] neighbour tables configuration via rtnetlink

[Thomas Graf]

* jamal <1110202499.1094.1371.camel@jzny.localdomain> 2005-03-07 08:34
> On Sat, 2005-03-05 at 12:22, Thomas Graf wrote:
> The patch overall looks ok although adventerous.
> What is it that requires you to change multiple parameters atomically? I
> cant seem to think of anything. I can see value in seeing some of these
> parameters in user space. Maybe.

Mainly because we have multiple applications that modify neighbour parameters
and they really have need to finish changing all parameters before another
application can look at them again. I solved this with a userspace lockfile
so far but this only catches applications that are aware of the lockfile.
The netlink method still leaves the gap open between fetching the data and
then changing it but that isn't a problem in my case and can be solved with
the netlink daemon for those who care.

> Some of the parameters you are dumping maybe dangerous if they are also
> allowed to be setable. As an example, changing a table name/id etc.
> I think you should review closely again what needs to be exposed.

Sure, not all dumpable parameters will be available for modification but
having them all available in userspace is definitely a good thing.

> I think this is reasonable. However - it is a lot of work. I will have
> no issues with seeing nothing else but netlink (even for ethtool like
> setups). There are certain things that would require more attention than
> others.

Yes, I think so as well but I really want to avoid putting effort into it
and then see it replaced with something else. I think Herbert once thought
about moving some of the rtnetlink stuff into a separate family and
restructuring the whole thing. Still plans there Herbert?

> I was going to write a simple patch to allow setting of indev
> parameters via netlink but havent had time. Started it but havent had
> time to revisit it - if you want to take over that one as well i could
> pass it on to you.

Sure, but I won't have time to actually work on it until next week.

> To achieve distributed configuration you dont need netlink. The main
> advantage of netlink over say /proc is the ability to do async events.
> [Yes, I know i have been shouting for taking netlink and and sending it
> over the wire and mucking around with endianness flags - but after
> practical considerations i am having second thoughts;] 

Yes I went through severeal iterations of thoughts as well but it still
seems reasonable to me. My current approach sounds quite silly but seems
to work out pretty well. It gets down to having libnl providing a XML input
and output interface and XSLT templates to convert every block into byte
order independant form and vice versa. I'm still toying around but I
already managed to convert my XML thingy into other protocols (given they
are at least somehow compatible in architecture). It is also quite simple
to convert these requests into a human readable form such as HTML and
have it placed onto a website for a operator to accept the change or to
simply keep a log of what has been changed when.

I'm not yet sure if it works out in the end but the goal is to reduce the
work needed to support a new rtnetlink object to the existance of a XSLT
stylesheet published somewhere and if possible have the XSLT processor
fetch it automatically from a local or global site. Other advantages?
Operators could modify the XSLT and add conditions and automatically
modify change requests to their needs.

Re: [RFC] neighbour tables configuration via rtnetlink

[jamal]

On Mon, 2005-03-07 at 09:26, Thomas Graf wrote:
> * jamal <1110202499.1094.1371.camel@jzny.localdomain> 2005-03-07 08:34
[..]
> Mainly because we have multiple applications that modify neighbour parameters
> and they really have need to finish changing all parameters before another
> application can look at them again. I solved this with a userspace lockfile
> so far but this only catches applications that are aware of the lockfile.
> The netlink method still leaves the gap open between fetching the data and
> then changing it but that isn't a problem in my case and can be solved with
> the netlink daemon for those who care.
> 

Sure - but this problem is not restricted to just this app of yours
but rather to the whole of netlink.
I am not questioning need for this approach - so lets forget about you
providing justification.

> > Some of the parameters you are dumping maybe dangerous if they are also
> > allowed to be setable. As an example, changing a table name/id etc.
> > I think you should review closely again what needs to be exposed.
> 
> Sure, not all dumpable parameters will be available for modification but
> having them all available in userspace is definitely a good thing.
> 

I would tend to agree

> > I think this is reasonable. However - it is a lot of work. I will have
> > no issues with seeing nothing else but netlink (even for ethtool like
> > setups). There are certain things that would require more attention than
> > others.
> 
> Yes, I think so as well but I really want to avoid putting effort into it
> and then see it replaced with something else. I think Herbert once thought
> about moving some of the rtnetlink stuff into a separate family and
> restructuring the whole thing. Still plans there Herbert?
> 

You will still need to grab the rtnl - so probably not much value in
creating a new netlink proto.

> > I was going to write a simple patch to allow setting of indev
> > parameters via netlink but havent had time. Started it but havent had
> > time to revisit it - if you want to take over that one as well i could
> > pass it on to you.
> 
> Sure, but I won't have time to actually work on it until next week.
> 

I have it on another machine - will send it later; if you havent
received it from me by the time you have cycles, please ping me.

> > To achieve distributed configuration you dont need netlink. The main
> > advantage of netlink over say /proc is the ability to do async events.
> > [Yes, I know i have been shouting for taking netlink and and sending it
> > over the wire and mucking around with endianness flags - but after
> > practical considerations i am having second thoughts;] 
> 
> Yes I went through severeal iterations of thoughts as well but it still
> seems reasonable to me. My current approach sounds quite silly but seems
> to work out pretty well. It gets down to having libnl providing a XML input
> and output interface and XSLT templates to convert every block into byte
> order independant form and vice versa. I'm still toying around but I
> already managed to convert my XML thingy into other protocols (given they
> are at least somehow compatible in architecture). It is also quite simple
> to convert these requests into a human readable form such as HTML and
> have it placed onto a website for a operator to accept the change or to
> simply keep a log of what has been changed when.
> 
> I'm not yet sure if it works out in the end but the goal is to reduce the
> work needed to support a new rtnetlink object to the existance of a XSLT
> stylesheet published somewhere and if possible have the XSLT processor
> fetch it automatically from a local or global site. Other advantages?
> Operators could modify the XSLT and add conditions and automatically
> modify change requests to their needs.

Yes, i think you are on the right track as far as using xnl. And if you
do that endianness issues dont exist (since XML is ascii). I would
advice (like i have many times on this) to not invent a protocol -
reusing something like netconf is the best approach. My understanding of
netconf though is a little dissapointing in that it does not do events
in the current version they are working on. I think events are supposed
to come post version 1.0 of the protocol.
I believe there is a open source project which does netconf already;
maybe all they need is just your library and xml interface ... I will
look it up and send you some pointers. 
BTW, what happened in the discussion with the gent who was doing SOAP
(or was going to do SOAP?)

cheers,
jamal

Re: [RFC] neighbour tables configuration via rtnetlink

[Thomas Graf]

* jamal <1110240219.1044.83.camel@jzny.localdomain> 2005-03-07 19:03
> On Mon, 2005-03-07 at 09:26, Thomas Graf wrote:
> > Yes, I think so as well but I really want to avoid putting effort into it
> > and then see it replaced with something else. I think Herbert once thought
> > about moving some of the rtnetlink stuff into a separate family and
> > restructuring the whole thing. Still plans there Herbert?
> 
> You will still need to grab the rtnl - so probably not much value in
> creating a new netlink proto.

I think so too, still it was worth deploying my sensors scanning for
possible changes to make sure the planned effort is worth it. :->

> Yes, i think you are on the right track as far as using xnl. And if you
> do that endianness issues dont exist (since XML is ascii). I would
> advice (like i have many times on this) to not invent a protocol -
> reusing something like netconf is the best approach. My understanding of
> netconf though is a little dissapointing in that it does not do events
> in the current version they are working on. I think events are supposed
> to come post version 1.0 of the protocol.

Absolutely, I plan to be compatible to as many existing protocols as
possible. The conceptual idea behind is to add another abstraction
layer before that protocol and have XSLT do the transformation into
those protocols.

The path could look like this:

    (netlink)  (API/daemon)    (XSLT)
Kernel  ->  libnl  ->  libnl_XML -> netconf

I left out the byte order issues here because I'm not yet sure how
to solve them although as stated already, using XSLT would be one
possible path to follow.

> I believe there is a open source project which does netconf already;
> maybe all they need is just your library and xml interface ... I will
> look it up and send you some pointers. 

You probably mean Yenca, I'm looking into it but it uses ioctl for
configuration and only implements a small subset of the functionality.
I've CC'ed Benjamin Zores which is stated as the author in the source
files.

> BTW, what happened in the discussion with the gent who was doing SOAP
> (or was going to do SOAP?)

The discussion somewhat stalled but I didn't forget about it. Having
the above architecture would allow to simply put the XML based
architecture indepedant change requests into SOAP envelopes and distribute
them.

Re: [RFC] neighbour tables configuration via rtnetlink

[jamal]

On Mon, 2005-03-07 at 20:37, Thomas Graf wrote:
> * jamal <1110240219.1044.83.camel@jzny.localdomain> 2005-03-07 19:03

[..]
> Absolutely, I plan to be compatible to as many existing protocols as
> possible. The conceptual idea behind is to add another abstraction
> layer before that protocol and have XSLT do the transformation into
> those protocols.
> 
> The path could look like this:
> 
>     (netlink)  (API/daemon)    (XSLT)
> Kernel  ->  libnl  ->  libnl_XML -> netconf
> 

That or you could have netconf just call libnl_something else (which i
have been trying to emphasize as the "the layer above libnl"). What you 
have above will work fine and i very flexible for netconf and maybe even
for SOAP like activities but will end running in a shell which at some
point will become a bottleneck.

> I left out the byte order issues here because I'm not yet sure how
> to solve them although as stated already, using XSLT would be one
> possible path to follow.
> 

There is no byte order issues with ASCII.

> > I believe there is a open source project which does netconf already;
> > maybe all they need is just your library and xml interface ... I will
> > look it up and send you some pointers. 
> 
> You probably mean Yenca,

Aha, yes - thats the one i saw.

>  I'm looking into it but it uses ioctl for
> configuration and only implements a small subset of the functionality.

Yes, i remember that code now. They do use ioctls. 
Unfortunately your libnl is not backward compatible and a lot of
embedded devices are 2.4.x based. Ive mentioned this before. You need to
provide a ioctl interface for some things as well and perhaps provide a
compile flag to select between the two.
On completion, I thin they had some basic stuff working which is a good
start (If i recall they could set ip addresses and routes). The
architecture seemed pretty sane to me; the whole was in the access to
the kernel configuration - they did something but it appeared weak.
This is where you could help i think.

> I've CC'ed Benjamin Zores which is stated as the author in the source
> files.
> 
> > BTW, what happened in the discussion with the gent who was doing SOAP
> > (or was going to do SOAP?)
> 
> The discussion somewhat stalled but I didn't forget about it. Having
> the above architecture would allow to simply put the XML based
> architecture indepedant change requests into SOAP envelopes and distribute
> them.
> 

Well, the way i see it is like this:

3rdlayer: netconf/someotherapp
secondlayer: "the layer above libnl" 
firstlayer: libnl (netlink level)
layer0: kernel

second layer is where that gents code would have been a good fit. He was
already providing some good APIs, bindings etc. XML could be just one
more binding.
The problem is i think you are trying to do all layers.

cheers,
jamal

Re: [RFC] neighbour tables configuration via rtnetlink

[Thomas Graf]

* jamal <1110290055.1043.183.camel@jzny.localdomain> 2005-03-08 08:54
> On Mon, 2005-03-07 at 20:37, Thomas Graf wrote:
> 
> [..]
> > The path could look like this:
> > 
> >     (netlink)  (API/daemon)    (XSLT)
> > Kernel  ->  libnl  ->  libnl_XML -> netconf
> > 
> 
> That or you could have netconf just call libnl_something else (which i
> have been trying to emphasize as the "the layer above libnl"). What you 
> have above will work fine and i very flexible for netconf and maybe even
> for SOAP like activities but will end running in a shell which at some
> point will become a bottleneck.

Possibily yes, I'm not quite sure why it would involve a shell at least
it is quite simple to work around using one but I tend to agree. What I'm
aiming for is some kind of generic request record format acting as base
for logging, distribution, whatever purpose and I think that is what you
mean with the "layer above libnl" so we're probably heading into the same
direction with minor differences in how to actually do it.

I'll keep on experimenting with it hoping to present some more detailed
results soon so we can redraw once we have some prototype and numbers.

> > I left out the byte order issues here because I'm not yet sure how
> > to solve them although as stated already, using XSLT would be one
> > possible path to follow.
> > 
> 
> There is no byte order issues with ASCII.

Obviously yes, it depends on at which layer the transformation is done
and that's the point I'm still unsure. The obvious way is to do it in
the actual module implementations of libnl and have the produced XML
protocol being aware of every single configuration bit. Another way
is to describe the actual netlink requests in a half-binary format and
do the transformation later. The latter saves a lot of transformation
work because everything in between doesn't need to be aware of all the
configuration possibilities. However, the transformation to other
protocol types gets more complicated. I haven't found any arguments
for either way that would convice me to head for one direction so I
planned to find out by experimenting.

> > You probably mean Yenca,
> [..]
> >  I'm looking into it but it uses ioctl for
> > configuration and only implements a small subset of the functionality.
> 
> Yes, i remember that code now. They do use ioctls. 
> Unfortunately your libnl is not backward compatible and a lot of
> embedded devices are 2.4.x based. Ive mentioned this before. You need to
> provide a ioctl interface for some things as well and perhaps provide a
> compile flag to select between the two.

Indeed, I'm not sure how to solve this properly though. libnl's scope
is already quite huge and it might be better to build another layer on
top of it (maybe the one you mentioned) which abstracts the whole network
configuration in a nice API automatically doing the right thing (tm)
by checking kernel capabilities an choose netlink/ioctl/ethtool/...
or whatever is appropriate.

> On completion, I thin they had some basic stuff working which is a good
> start (If i recall they could set ip addresses and routes).

>From what the source tells me, interface and routing has been partially
implemented which is a nice start. The code could be merged into the
above mentioned library acting as interface for netconf to interact
with the kernel.

> The architecture seemed pretty sane to me; the whole was in the access to
> the kernel configuration - they did something but it appeared weak.
> This is where you could help i think.

I'll try to work this out with Benjamin given it is in his interest.

> Well, the way i see it is like this:
> 
> 3rdlayer: netconf/someotherapp
> secondlayer: "the layer above libnl" 
> firstlayer: libnl (netlink level)
> layer0: kernel
> 
> second layer is where that gents code would have been a good fit. He was
> already providing some good APIs, bindings etc. XML could be just one
> more binding.

Agreed.

> The problem is i think you are trying to do all layers.

I'm thinking in all layers to not miss anything important but it should
definitely be spread across various independant parts.

Re: [RFC] neighbour tables configuration via rtnetlink

[jamal]

On Tue, 2005-03-08 at 09:27, Thomas Graf wrote:
> * jamal <1110290055.1043.183.camel@jzny.localdomain> 2005-03-08 08:54
[..]
> 
> Possibily yes, I'm not quite sure why it would involve a shell at least

Ok, I could be wrong - if you use some xml library that has xslt library
then you should be fine.

> it is quite simple to work around using one but I tend to agree. What I'm
> aiming for is some kind of generic request record format acting as base
> for logging, distribution, whatever purpose and I think that is what you
> mean with the "layer above libnl" so we're probably heading into the same
> direction with minor differences in how to actually do it.
> 

I am thinking API. And the reason i sensed you and the gnome guy had a
good fit was he had this API, it may have to be refined. 

> I'll keep on experimenting with it hoping to present some more detailed
> results soon so we can redraw once we have some prototype and numbers.
> 

makes sense 


> > There is no byte order issues with ASCII.
> 
> Obviously yes, it depends on at which layer the transformation is done
> and that's the point I'm still unsure. The obvious way is to do it in
> the actual module implementations of libnl and have the produced XML
> protocol being aware of every single configuration bit. Another way
> is to describe the actual netlink requests in a half-binary format and
> do the transformation later. The latter saves a lot of transformation
> work because everything in between doesn't need to be aware of all the
> configuration possibilities. However, the transformation to other
> protocol types gets more complicated. I haven't found any arguments
> for either way that would convice me to head for one direction so I
> planned to find out by experimenting.
> 

Well, xml transfered from remote configuration machine.
application takes xml and through some magic layer (either xslt
transform etc) makes a change a call to gnome-dudes API.
Gnome-dude's api calls libnl. libnl calls netlink to kernel.
Since the remote calls terminate at the layer above gnome-dude you
shouldnt have to worry.

> > Yes, i remember that code now. They do use ioctls. 
> > Unfortunately your libnl is not backward compatible and a lot of
> > embedded devices are 2.4.x based. Ive mentioned this before. You need to
> > provide a ioctl interface for some things as well and perhaps provide a
> > compile flag to select between the two.
> 
> Indeed, I'm not sure how to solve this properly though. libnl's scope
> is already quite huge and it might be better to build another layer on
> top of it (maybe the one you mentioned) which abstracts the whole network
> configuration in a nice API automatically doing the right thing (tm)
> by checking kernel capabilities an choose netlink/ioctl/ethtool/...
> or whatever is appropriate.

Well, use netlink at all times. But for sucess you MUST have backward
compatibility. And this may mean a compile config (make config) which
has a selection to use ioctls when they are available (only two i can
really think of in rtnelink that are reklevant are IFLA and IFA).

> > On completion, I thin they had some basic stuff working which is a good
> > start (If i recall they could set ip addresses and routes).
> 
> From what the source tells me, interface and routing has been partially
> implemented which is a nice start. The code could be merged into the
> above mentioned library acting as interface for netconf to interact
> with the kernel.
> 

Well, i think theres a very clean separation. They have a few functions
which convert from XML to add routes etc. Thats the part that needs to
call "api above libnl" which calls libnl IMO.
in other words you are providing these services to them.


> > The problem is i think you are trying to do all layers.
> 
> I'm thinking in all layers to not miss anything important but it should
> definitely be spread across various independant parts.
> 

Understood - I am just saying this is huuge amounts of work; you may
wanna involve the gnome guy and let him worry about "the layer above
libnl". I would be more than happy to participate in the discussions
for what the API should be (many many opinions based on experience)
without necessarily commiting that i will have time to code anything.

cheers,
jamal

Re: [RFC] neighbour tables configuration via rtnetlink

[David S. Miller]

On Sat, 5 Mar 2005 18:22:57 +0100
Thomas Graf <tgraf@suug.ch> wrote:

> Before I go ahead, putting more effort into it, what is our preferred
> interface for network configuration? My personal preference is to make
> everything available via netlink with the long term plan to extend it
> with distributive remote configuration protocol in userspace. If so,
> shall we continue to push everything into rtnetlink regardless of the
> association to routing? The only drawback of the currently "overloaded"
> rtnetlink is the rtnl semaphore which has grown into something like
> the BKL for networking. I'm not aware of any performance problems or
> other issues because of this except for the module loading over nfs.
> Does anyone?
> 
> Thoughts?

Perhaps we shouldn't try to assosciate the rtnl semaphore with lock_kernel().
It really is more of a write lock than a lock which protects both reads
and writes.  (yes, I realize the rtnl packet processing code holds this
thing for all messages, not just ones which modify config state)

It is always going to be tempting to finer-grain the rtnl semaphore, but
just about every single RTNL state change has some trickle down effect on
some generic network device setting.  So at that moment any attempt to
fine-grain the locking for an RTNL operation fails.

It is tempting to consider a hierarchy of locks, with a locking order
such that generic netdev stuff sits at the bottom.  But welcome to an
AB<-->BA deadlock city as we hit generic device state changes which cause
modification of protocol specific addressing and routing state.

Back to the main topic, Thomas do you plan to complete this rtnetlink'ification
of neigh for the 2.6.13 timeframe?