On the "location of the data" issue, I have some comment.
The users of prefix list data don't know the prefix or the prefix length;
they know the interface index, and need to get the prefixes.
The data is fundamentally per-interface, and the routing table is
per-destination. So, adding the prefixes to the routing table doesn't seem
like the best choice because everything that currently uses the routing
table will have to skip over these extra entries (which they'll never be
interested in) and the users of the prefix data will have to skip over all
existing routing table entries (which they're never interested in).
Routes and prefixes are independent of each other, so throwing them in the
same table to me seems like it only creates work to skip entries that
aren't related, and because the users of the prefix data don't have the key
needed for a fast look-up in the routing table, prefix users in particular
have to skip through everything currently in the routing table, linearly,
with no benefit at all for being there.
I also see no relation between prefix list data and the FIB; current users
are completely independent from prefix list users, and it appears to only
slow both of them down. The prefix data is always looked-up by interface
index, so I think it really belongs in the inet6 per-interface structure,
unless I'm missing something. What benefits are there for lumping this with
existing data structures that aren't per-interface, or keyed per-interface?
+-DLS
YOSHIFUJI Hideaki / 吉藤英明 [off-list ref]@vger.kernel.org on
05/30/2003 07:02:49 PM
Sent by: linux-net-owner@vger.kernel.org
To: krkumar@us.ltcfwd.linux.ibm.com
cc: davem@redhat.com, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org,
netdev@oss.sgi.com, linux-net@vger.kernel.org
Subject: Re: [PATCH] Prefix List patch against 2.5.70
In article [off-list ref] (at Fri, 30 May 2003 18:15:28
-0700), Krishna Kumar [off-list ref] says:
+/* prefix list returned to user space in this structure */
+struct plist_user_info {
^ip6 or ipv6 or so.
+ char name[IFNAMSIZ]; /* interface name */
~~~~~~~~~~~~~~~~~~~duplicate information.
quoted hunk
+ int ifindex; /* interface index */
+ int nprefixes; /* number of elements in 'prefix' */
+ struct var_plist_user_info { /* multiple elements */
+ char flags[3]; /* router advertised flags */
~~~~~~~~this is not good interface.
quoted hunk
+ int plen; /* prefix length */
+ __u32 valid; /* valid lifetime */
+ struct in6_addr ra_addr;/* advertising router */
+ struct in6_addr prefix; /* prefix */
+ } plist_vars[0];
+};
+
extern void addrconf_init(void);
extern void addrconf_cleanup(void);
:
I think we should use 1 fixed-length message per prefix,
instead of variable length message.
quoted hunk
+ pinfo->plist_vars[count].plen = p_el->pinfo.prefix_len;
+ pinfo->plist_vars[count].valid = p_el->pinfo.valid -
+ (jiffies - p_el->timestamp)/HZ;
+ if ((p_el->ra_flags & (ND_RA_FLAG_MANAGED |
+ ND_RA_FLAG_OTHER))
+ == (ND_RA_FLAG_MANAGED|ND_RA_FLAG_OTHER))
+ strcpy(pinfo->plist_vars[count].flags, "MO");
+ else if (p_el->ra_flags & ND_RA_FLAG_MANAGED)
+ strcpy(pinfo->plist_vars[count].flags, "M");
+ else if (p_el->ra_flags & ND_RA_FLAG_OTHER)
+ strcpy(pinfo->plist_vars[count].flags, "O");
+ else
+ strcpy(pinfo->plist_vars[count].flags, "-");
+ ipv6_addr_copy(&pinfo->plist_vars[count].ra_addr,
+ &p_el->ra_addr);
+ for (i = 0; i < 8; i++)
+ pinfo->plist_vars[count].ra_addr.s6_addr16[i] =
+
__constant_ntohs(pinfo->plist_vars[count].ra_addr.s6_addr16[i]);
quoted hunk
+ ipv6_addr_copy(&pinfo->plist_vars[count].prefix,
+ &p_el->pinfo.prefix);
+ for (i = 0; i < p_el->pinfo.prefix_len/16; i++)
+ pinfo->plist_vars[count].prefix.s6_addr16[i] =
+
__constant_ntohs(pinfo->plist_vars[count].prefix.s6_addr16[i]);
Absoletely nasty.
- don't use charaters to represent flags; use real flags.
- use network-byte order.
+static int prefix_list_proc_dump(char *buffer, char **start, off_t
offset,
+ int length)
+{
:
Please use seq_file.
Again, what I proposed was to store prefix information on fib with
some flags to represent advertised by routers and give user-space
the RA information using new rtattr (RTA_RA6INFO or something like that).
struct rta_ra6info {
u32 rta_ra6flags;
};
--
Hideaki YOSHIFUJI @ USAGI Project [off-list ref]
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2 Jun 2003, David Stevens wrote:
The users of prefix list data don't know the prefix or the prefix
length; they know the interface index, and need to get the prefixes.
The data is fundamentally per-interface, and the routing table is
per-destination. So, adding the prefixes to the routing table doesn't seem
like the best choice because everything that currently uses the routing
table will have to skip over these extra entries (which they'll never be
interested in)
Umm.. every prefix should have an interface route, so they're a required
subset of the routing table, correct?
and the users of the prefix data will have to skip over all
existing routing table entries (which they're never interested in).
...
Routes and prefixes are independent of each other, so throwing them in the
same table to me seems like it only creates work to skip entries that
aren't related, and because the users of the prefix data don't have the key
needed for a fast look-up in the routing table, prefix users in particular
have to skip through everything currently in the routing table, linearly,
with no benefit at all for being there.
I also see no relation between prefix list data and the FIB; current users
are completely independent from prefix list users, and it appears to only
slow both of them down. The prefix data is always looked-up by interface
index, so I think it really belongs in the inet6 per-interface structure,
unless I'm missing something. What benefits are there for lumping this with
existing data structures that aren't per-interface, or keyed per-interface?
+-DLS
YOSHIFUJI Hideaki / $B5HF#1QL@(B [off-list ref]@vger.kernel.org on
05/30/2003 07:02:49 PM
Sent by: linux-net-owner@vger.kernel.org
To: krkumar@us.ltcfwd.linux.ibm.com
cc: davem@redhat.com, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org,
netdev@oss.sgi.com, linux-net@vger.kernel.org
Subject: Re: [PATCH] Prefix List patch against 2.5.70
In article [off-list ref] (at Fri, 30 May 2003 18:15:28
-0700), Krishna Kumar [off-list ref] says:
quoted
+/* prefix list returned to user space in this structure */
+struct plist_user_info {
^ip6 or ipv6 or so.
quoted
+ char name[IFNAMSIZ]; /* interface name */
~~~~~~~~~~~~~~~~~~~duplicate information.
quoted
+ int ifindex; /* interface index */
+ int nprefixes; /* number of elements in 'prefix' */
+ struct var_plist_user_info { /* multiple elements */
+ char flags[3]; /* router advertised flags */
~~~~~~~~this is not good interface.
quoted
+ int plen; /* prefix length */
+ __u32 valid; /* valid lifetime */
+ struct in6_addr ra_addr;/* advertising router */
+ struct in6_addr prefix; /* prefix */
+ } plist_vars[0];
+};
+
extern void addrconf_init(void);
extern void addrconf_cleanup(void);
:
I think we should use 1 fixed-length message per prefix,
instead of variable length message.
quoted
+ pinfo->plist_vars[count].plen = p_el->pinfo.prefix_len;
+ pinfo->plist_vars[count].valid = p_el->pinfo.valid -
+ (jiffies - p_el->timestamp)/HZ;
+ if ((p_el->ra_flags & (ND_RA_FLAG_MANAGED |
+ ND_RA_FLAG_OTHER))
+ == (ND_RA_FLAG_MANAGED|ND_RA_FLAG_OTHER))
+ strcpy(pinfo->plist_vars[count].flags, "MO");
+ else if (p_el->ra_flags & ND_RA_FLAG_MANAGED)
+ strcpy(pinfo->plist_vars[count].flags, "M");
+ else if (p_el->ra_flags & ND_RA_FLAG_OTHER)
+ strcpy(pinfo->plist_vars[count].flags, "O");
+ else
+ strcpy(pinfo->plist_vars[count].flags, "-");
+ ipv6_addr_copy(&pinfo->plist_vars[count].ra_addr,
+ &p_el->ra_addr);
+ for (i = 0; i < 8; i++)
+ pinfo->plist_vars[count].ra_addr.s6_addr16[i] =
+
__constant_ntohs(pinfo->plist_vars[count].ra_addr.s6_addr16[i]);
quoted
+ ipv6_addr_copy(&pinfo->plist_vars[count].prefix,
+ &p_el->pinfo.prefix);
+ for (i = 0; i < p_el->pinfo.prefix_len/16; i++)
+ pinfo->plist_vars[count].prefix.s6_addr16[i] =
+
__constant_ntohs(pinfo->plist_vars[count].prefix.s6_addr16[i]);
Absoletely nasty.
- don't use charaters to represent flags; use real flags.
- use network-byte order.
quoted
+static int prefix_list_proc_dump(char *buffer, char **start, off_t
offset,
quoted
+ int length)
+{
:
Please use seq_file.
Again, what I proposed was to store prefix information on fib with
some flags to represent advertised by routers and give user-space
the RA information using new rtattr (RTA_RA6INFO or something like that).
struct rta_ra6info {
u32 rta_ra6flags;
};
--
Hideaki YOSHIFUJI @ USAGI Project [off-list ref]
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
From: Pekka Savola [off-list ref]
Date: Tue, 3 Jun 2003 07:48:13 +0300 (EEST)
Umm.. every prefix should have an interface route, so they're a required
subset of the routing table, correct?
That's entirely correct, thanks for noticing this :-)
This is why I said that they could add to a global list
all routes that meet this criteria. Thus making any
querying mechanism simple to implement.