From: Krishna Kumar <krkumar@us.ibm.com>
To: yoshfuji@linux-ipv6.org
Cc: davem@redhat.com, netdev@oss.sgi.com, linux-net@vger.kernel.org,
kuznet@ms2.inr.ac.ru
Subject: Re: [PATCH] Prefix List against 2.5.70 (re-done)
Date: Thu, 10 Jul 2003 15:16:25 -0700 [thread overview]
Message-ID: <3F0DE5B9.20702@us.ibm.com> (raw)
In-Reply-To: <20030702.091825.72842784.yoshfuji@linux-ipv6.org>
> You do not explain why we (or kernel) NEED(s) this.
> It is not so important how SMALL it is
> though it may cause problems how LARGE it is.
I had explained the reasons for having prefix list i/f in my previous mail. To recap :
- User don't need to know what the definition of a prefix is, all he has to do is ask
the kernel and get the list. Otherwise different user apps will have to know the
definition of a prefix and parse the entry themselves. The parsing is non-trivial (eg
the address should not LL or MC, there should be no nexthop and it should be added via
an RA, etc).
- The kernel code to get the prefix list is small, the top level inet6_dump_fib uses
either the dump_node or the dump_prefix, the latter being the new user interface. Having
a user interface makes it easier to get the prefix list without significant bloat to the
kernel.
> This is design issue; how we should provide L3 per-interface
> information to userspace; eg. in_device and/or inet6_dev things
> including per-interface statistics.
>
> Since I think it is not appropriate to provide per-interface
> statistics via RTM_xxxROUTE, so I don't agree to provide
> the RA infomation (i.e. Manage/Otherconf Flags) via
> RTM_xxxROUTE.
>
> Options:
> - use RTM_xxxLINK for L3 operation
> - introduce RTM_xxxIFACE for L3 per-interface operations
Yes, there are a couple of different ways to do this. One is as you have suggested, but there
is a problem with it. The existing RTM_GETLINK interface returns very generic elements of the
dev (mtu, hardware address, dev statistics), while the change you suggested is specific to
ipv6. I am not sure if this is a good design to implement. Either we could use the current
(submitted) way or use a different RTM_GETADDR interface in inet6_fill_ifaddr (and introduce
RTM_IFACEFLAGS). This will be specific to IPv6. Are you agreeable to this ?
> Well, on moving forward; you can split your patch up to 3 things:
> 1. fix routing flags
> 2. provide Managed/Otherconf flags API
> (3. provide the prefix list API (if it IS required))
>
> I'm not against the first item.
> We need to discuss on the design related to the 2nd item.
> I don't think that we really need 3rd item.
- I am ok with 1 :-)
- I have suggested changes for 2, please let me know what you think, whether we can go with the
old way or make the change suggested above.
- I believe we need #3 for the reasons given above.
Thanks,
- KK
next prev parent reply other threads:[~2003-07-10 22:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-20 20:53 [PATCH] Prefix List against 2.5.70 (re-done) Krishna Kumar
2003-06-21 14:36 ` YOSHIFUJI Hideaki / 吉藤英明
2003-06-25 17:02 ` Krishna Kumar
2003-06-26 6:42 ` David S. Miller
2003-06-26 16:32 ` Krishna Kumar
2003-06-27 6:07 ` David S. Miller
2003-06-27 15:45 ` Krishna Kumar
2003-06-27 21:47 ` David S. Miller
2003-06-28 4:06 ` YOSHIFUJI Hideaki / 吉藤英明
2003-06-30 18:54 ` Krishna Kumar
2003-07-02 0:18 ` YOSHIFUJI Hideaki / 吉藤英明
2003-07-10 22:16 ` Krishna Kumar [this message]
2003-06-26 22:40 ` [PATCH] Prefix List against 2.4.21 Krishna Kumar
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=3F0DE5B9.20702@us.ibm.com \
--to=krkumar@us.ibm.com \
--cc=davem@redhat.com \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-net@vger.kernel.org \
--cc=netdev@oss.sgi.com \
--cc=yoshfuji@linux-ipv6.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.