| To: | Andi Kleen <ak@xxxxxx> |
|---|---|
| Subject: | Re: netlink drops messages. |
| From: | Werner Almesberger <Werner.Almesberger@xxxxxxx> |
| Date: | Wed, 17 Jan 2001 21:36:34 +0100 |
| Cc: | netdev@xxxxxxxxxxx |
| In-reply-to: | <20010117184852.A7146@fred.local>; from ak@muc.de on Wed, Jan 17, 2001 at 06:48:52PM +0100 |
| References: | <20010116124319.D1299@doit.wisc.edu> <200101161848.VAA31729@ms2.inr.ac.ru> <20010116131456.E1299@doit.wisc.edu> <20010117040542.Y18286@almesberger.net> <20010117121532.B1830@fred.local> <20010117074952.C2459@doit.wisc.edu> <20010117171310.A5589@fred.local> <20010117110035.G2459@doit.wisc.edu> <20010117184852.A7146@fred.local> |
| Sender: | owner-netdev@xxxxxxxxxxx |
Andi Kleen wrote: > What you should implement in your application depends on what you need to > handle, I think what James means is that there's nothing between being able to handle a small number of changes efficiently and the possibly very inefficient full dump, even though in some cases (e.g. if you have a large but fairly static collection of items which only change state, but don't get created or destroyed all the time), a selective yet scalable notification mechanism would be possible (as outlined in previous messages in this thread). But I'm not sure whether the scenario in question is sufficiently close to real life to justify any optimization. - Werner -- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH Werner.Almesberger@xxxxxxx / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/ |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: routable interfaces, kuznet |
|---|---|
| Next by Date: | Re: netlink drops messages., James R. Leu |
| Previous by Thread: | Re: netlink drops messages., jamal |
| Next by Thread: | Re: netlink drops messages., Michael Richardson |
| Indexes: | [Date] [Thread] [Top] [All Lists] |