From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Thu, 11 May 2006 10:40:37 +0400
> > It is absolutely necessary to find ways to get rid of these layering
> > costs. "Layering is how you design networking protocols, not how you
> > implement them."
>
> If I provide a patch which will allow to mark special socket as
> no-protocol-and-any-upper-layer-lookup, but instead process skb->data
> (like copying to userspace, or just allow recv() to return without any
> copy) and performance will not differ from what we have with layers,
> will it justify that not abstract cache trashing and lookup split into
> socket/route are not the problem?
>
> Or have you switched from engineering to researching mode? :)
You test with single socket and single source ID, what do you expect?
Everything is hot in the cache, as expected.
It is not research, I did put cycle counter sampling all over these
spots on sparc64 a long time ago just to familiarize myself with where
cpu spends most of it's time in softint processing when there are lots
of sockets and unique remote addresses.
And most of the time from netif_receive_skb() to the meat of
{udp,tcp}_rcv() is touching the routing cache and socket demux hash
tables. Add bonus costs to netfilter if that is enabled too. Once
you are past that point, for TCP, tcp_ack() is the primary cpu cycle
eater.
You can test with single stream, but then you are only testing
in-cache case. Try several thousand sockets and real load from many
unique source systems, it becomes interesting then.
>From profiles of heavily used web server, what shows up is bulk of cpu
being in socket demux and tcp_ack(). Next bubble is routing cache.
I have not seen good profiles from a heavy web server employing any
real use of netfilter, that would be interesting as well.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
