[ OK, this time I cc'ed netdev 8-) ]
On Fri, 1 Jun 2001, Alan Cox wrote:
> Please re-read your comment. Then think about it. Then tell me how rate
> limiting differs from caching to the application.
For caching, the kernel establishes the rate with which the info is
updated. There's nothing wrong, but how is the application to know if the
value is actual or cached (from when, until when) ? That means that a
single application that needs data more often than the caching rate will
get bogus data and not know about it.
With rate limiting, you always get new values, unless the limit is
exceeded. When the limit is exceeded, you log and:
- block any request until some timer is expired. The application can
detect that it's been blocked and react. You can detect if there are
several calls waiting and return the same value to all.
- return error until some timer is expired. The application can again
detect that.
In both cases, the application is also capable of guessing the value of
the delay.
For one application which follows the rules (doesn't need data more often
than the caching rate or doesn't exceed the rate limit) there is no
difference, I agree. But when somebody is playing tricks while you need
data, you have the chance of detecting this by using rate limits.
And yes, I agree that either of them (cache or rate limit) should be
modifiable through proc entry/ioctl/whatever.
-- Bogdan CostescuIWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 07 2001 - 21:00:15 EST