netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Graf <tgraf@suug.ch>
To: jamal <hadi@cyberus.ca>
Cc: "David S. Miller" <davem@davemloft.net>, netdev@oss.sgi.com
Subject: Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink
Date: Fri, 27 May 2005 17:16:08 +0200	[thread overview]
Message-ID: <20050527151608.GZ15391@postel.suug.ch> (raw)
In-Reply-To: <1117205822.6383.68.camel@localhost.localdomain>

* jamal <1117205822.6383.68.camel@localhost.localdomain> 2005-05-27 10:57
> The thresholds etc are there - just not netlink accessible. Example, the
> default values for V4 are settable or queriable via:
> 
> /proc/sys/net/ipv4/neigh/default/gc_thresh3
> /proc/sys/net/ipv4/neigh/default/gc_thresh2
> /proc/sys/net/ipv4/neigh/default/gc_thresh1
> /proc/sys/net/ipv4/neigh/default/gc_interval

Sorry but this is just one big hack:

a) they do not belong there, the first implication a user does when
   he sees default/, dev1/, dev2/, devN is that default/ covers
   the same set of parameters as devX/. Therefore he expects all
   parameters in default/ to be also in devX/.

b)	struct neigh_parms	parms;
	/* HACK. gc_* shoul follow parms without a gap! */
	int			gc_interval;
	int			gc_thresh1;
	int			gc_thresh2;
	int			gc_thresh3;

...

	if (dev) {
		dev_name_source = dev->name;
		t->neigh_dev[0].ctl_name = dev->ifindex;
		t->neigh_vars[12].procname = NULL; <- gc_interval
		t->neigh_vars[13].procname = NULL; <- gc_thresh1
		t->neigh_vars[14].procname = NULL; <- gc_thresh2
		t->neigh_vars[15].procname = NULL; <- gc_thresh3
	} else {
 		dev_name_source = t->neigh_dev[0].procname;
		t->neigh_vars[12].data = (int *)(p + 1);
		t->neigh_vars[13].data = (int *)(p + 1) + 1;
		t->neigh_vars[14].data = (int *)(p + 1) + 2;
		t->neigh_vars[15].data = (int *)(p + 1) + 3;
	}

  I will not push along these hacks into my code ;->

Some more notes on the devconfig idea: I'm not sure if you are still
implying devconfig as devinet but if so: although we only have neighbour
tables on devinets so far there might be neighbour table on other
interfaces for whatever reason. A protocol might allocate a neighbour
parameter set on any netdevice which makes me think that the netlink
neighbour code should be open for this as well. It depends on how we
do the devconfig thing, so what I suggest it so leave this as-is for
the moment and make a decision once we know more about how the devconfig
thing will look like. Reasonable?

> I apologize i didnt comment on the patch earlier - sometimes when i am
> away from the list for sometime i skip threads which may require me to
> spend time looking at them to make any useful comments. This maybe the
> reason i didnt respond. To catchup i normally read emails addressed to
> me first then go over the list in a LIFO mode and stop once i get
> engaged in a discussion.

I should have CCed you, my fault.

  reply	other threads:[~2005-05-27 15:16 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-26 18:53 [PATCHSET] neighbour tables access via rtnetlink Thomas Graf
2005-05-26 18:54 ` [PATCH 1/4] [NETLINK] New message building macros Thomas Graf
2005-05-26 18:54 ` [PATCH 2/4] [RTNETLINK] Routing attribute related shortcuts Thomas Graf
2005-05-26 18:55 ` [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink Thomas Graf
2005-05-26 22:17   ` David S. Miller
2005-05-26 22:24     ` Thomas Graf
2005-05-26 22:26     ` Thomas Graf
2005-05-26 22:37       ` David S. Miller
2005-05-27 11:14   ` jamal
2005-05-27 12:15     ` Thomas Graf
2005-05-27 13:50       ` jamal
     [not found]         ` <20050527141023.GP15391@postel.suug.ch>
2005-05-27 14:57           ` jamal
2005-05-27 15:16             ` Thomas Graf [this message]
2005-05-27 15:56               ` jamal
2005-05-27 16:35                 ` Thomas Graf
2005-05-28  1:42                   ` jamal
2005-05-28 12:07                     ` Thomas Graf
2005-05-31 10:04                       ` jamal
2005-05-31 11:42                         ` Thomas Graf
2005-05-31 12:48                           ` jamal
2005-05-31 13:17                             ` Thomas Graf
2005-05-31 14:59                               ` Jamal Hadi Salim
2005-05-31 16:13                                 ` Thomas Graf
2005-06-02 13:33                                   ` jamal
2005-05-26 18:55 ` [NEIGH] Remove unused fields in struct neigh_parms and neigh_table Thomas Graf
2005-05-26 19:00   ` Thomas Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050527151608.GZ15391@postel.suug.ch \
    --to=tgraf@suug.ch \
    --cc=davem@davemloft.net \
    --cc=hadi@cyberus.ca \
    --cc=netdev@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).