In article <200307250437.50928.fredrik@dolda2000.cjb.net> you wrote:
> I almost thought that would be it. I do understand that that code needs to be
> really clean, but, correct me if I'm wrong, but isn't GCC's long long
> implementation efficient enough to only add minimal overhead to that?
I think there is mainly an issue with atomic incremets. I am not sure if the
counter can be incremeted concurrently, or if the code path would be
serialized, but there is always the reading side, which may need to retry an
read. Besides that, the counter is in the fast path, so it will add some
delay to packet handling.
I guess a 64bit implementation will need to be a per-cpu solution.
Greetings
Bernd
-- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/ - 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 Jul 31 2003 - 22:00:24 EST