Grr, I've almost lost this... In article <3EF37458.3070103@us.ibm.com> (at Fri, 20 Jun 2003 13:53:44 -0700), Krishna Kumar <krkumar@us.ibm.com> says: > 1. I change the netlink_dump_start to pass another parameter, <type>, which is > stored in a new field in the cb, <type>. All users of this function have been > changed to pass a -1 since they don't care about the type, except the > generic routine rtnetlink_rcv_msg() which calculates the type and stores it. > So the same routine which is used to dump route table can be used to dump > the prefix list by checking the type. It might be possible to derive the > type from the table offset, but that is more complicated (probably doable). I think this is not required. Rename inet6_dump_fib() to __inet6_dump_fib() and introduce extra argument. and call it like inet6_dump_fib() { __inet6_dump_fib(...,0); } and inet6_dump_prefix() { __inet6_dump_fib(...,1); } etc. > 3. Added user interface for retrieving M/O flags. This is a separate interface > from the one for getting the prefix list since the flags are per interface > while the prefix list is per route. However these two can be merged into one > if needed. Hmm, what I expected is to get information via RTA_NEWLINK message. This is because, this is per-interface thing. > 5. Though this patch is modified to use only routing table for updating and > accessing the prefix list, I did a performace analysis for this approach vs > storing the plist on the idev. Following is the result : > > System : 1 CPU. 866 MHz, 256MB memory > For 1000 VLAN devices (4036 route entries gets created automatically as part > of address assignment), retrieve prefix list for (system times only) : > > #devices #iteration for each dev plist on IDEV plist in RTTABLE % > 200 100 3.95 secs 40.14 secs 916% > 1000 10 2.60 secs 20.98 secs 706% > 200 1000 38.44 secs 400.76 secs 942% Hmm... Well, what should we do... -- Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org> GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA - : 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
