> I'm not talking about cpu second level cache, I'm talking about
> a second level lookup table that backs up a front end routing
> hash. A software data structure.
Doh! Sorry for my confusion, I guess I wasn't reading your posting too
carefully. I understand the software architecture part now. Nevertheless
one day or another you will need to face the caching issue too unless
your data structure will always fit entirely into the cache or am I
completely off track again?
> You are talking about a lot of independant things, but I'm going
> to defer my contributions until we have actual code people can
> start plugging netfilter into if they want.
Fair enough. I'm looking forward to seeing this framework. Any release
schedules or rough plans?
> About using syslog to record messages, that is doomed to failure,
> implement log messages via netlink and use that to log the events
> instead.
Yes, we're doing tests in this field now (as with evlog) but as it seems
from preliminary testing netlink transportation of binary data is not
100% reliable either. However, I will refrain from further posting
assumptions until we've done our tests and until we can post useful
results and facts in this field.
Thanks and cheers,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
From: Roberto Nibali <[email protected]>
Date: Thu, 26 Sep 2002 11:24:19 +0200
Fair enough. I'm looking forward to seeing this framework. Any release
schedules or rough plans?
None whatsoever, as it should be.
Franks a lot,
David S. Miller
[email protected]
On Thu, 26 Sep 2002, Roberto Nibali wrote:
> Yes, we're doing tests in this field now (as with evlog) but as it seems
> from preliminary testing netlink transportation of binary data is not
> 100% reliable either.
Non-blocking netlink delivery is reliable, although you can overrun the
userspace socket buffer (this can be detected, however). The fundamental
issue remains: sending more data to userspace than can be handled.
A truly reliable transport would also involve an ack based protocol .
Under certain circumstances (e.g. log every forwarded packet for audit
purposes), packets would need to be dropped if the logging mechanism
became overloaded. This would in turn involve some kind of queuing
mechanism and introduce a new set of performance problems. Reliable
logging is a challenging problem area in general, probably better suited
to dedicated hardware environments where the software can be tuned to
known system capabilities.
- James
--
James Morris
<[email protected]>