[Top] [All Lists]

Re: Route cache performance under stress

To: "John S. Denker" <jsd@xxxxxxxxxxxx>
Subject: Re: Route cache performance under stress
From: Jamal Hadi <hadi@xxxxxxxxxxxxxxxx>
Date: Tue, 10 Jun 2003 08:12:58 -0400 (EDT)
Cc: Pekka Savola <pekkas@xxxxxxxxxx>, ralph+d@xxxxxxxxx, CIT/Paul <xerox@xxxxxxxxxx>, "'Simon Kirby'" <sim@xxxxxxxxxxxxx>, "'David S. Miller'" <davem@xxxxxxxxxx>, "fw@xxxxxxxxxxxxx" <fw@xxxxxxxxxxxxx>, "netdev@xxxxxxxxxxx" <netdev@xxxxxxxxxxx>, "linux-net@xxxxxxxxxxxxxxx" <linux-net@xxxxxxxxxxxxxxx>
In-reply-to: <3EE5C7E9.6090401@xxxxxxxxxxxx>
References: <Pine.LNX.4.44.0306101432530.21247-100000@xxxxxxxxxx> <3EE5C7E9.6090401@xxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx

On Tue, 10 Jun 2003, John S. Denker wrote:

> On 06/10/2003 07:41 AM, Pekka Savola wrote:
> >
> >>Typical packet is around 500 bytes
> >>average.
> >
> > Not sure that's really the case.  I have the impression the traffic is
> > basically something like:
> >  - close to 1500 bytes (data transfers)
> >  - between 40-100 bytes (TCP acks, simple UDP requests, etc.)
> >  - something in between
> It helps to take a more sophisticated view of things.
> In typical networks:
> Most of the packet-count is to be found in small packets.
> Most of the byte-count is to be found in large packets.
> Some things (e.g. routing) depend mainly on the packet-count.
> Other things (e.g. encryption, layer-1 hardware requirements,
> memory bandwidth usage, ISP contracts) are sensitive to the
> byte-count.
> We shouldn't optimize one at the expense of the other.

You bring a good point.
Theres another dimension actually: mostly driven by BSD mbuff style
packet allocation; some tests show that some vendors are optimized
for certain packet sizes, Linux skbuffs dont have this problem.
We dont optimize for packet sizes given the linear nature of skbuffs.
Donalds ether drivers tend to amortize some of the costs by reallocating
skbs when the packet <= 100 bytes, but this is no longer valid with
skb recycling and the magazine layer appearing in the slab.


<Prev in Thread] Current Thread [Next in Thread>