netdev
[Top] [All Lists]

Re: RFC: NAPI packet weighting patch

To: "David S. Miller" <davem@xxxxxxxxxxxxx>
Subject: Re: RFC: NAPI packet weighting patch
From: P@xxxxxxxxxxxxxx
Date: Wed, 22 Jun 2005 09:42:56 +0100
Cc: gandalf@xxxxxxxxxxxxxx, hadi@xxxxxxxxxx, shemminger@xxxxxxxx, mitch.a.williams@xxxxxxxxx, john.ronciak@xxxxxxxxx, mchan@xxxxxxxxxxxx, buytenh@xxxxxxxxxxxxxx, jdmason@xxxxxxxxxx, netdev@xxxxxxxxxxx, Robert.Olsson@xxxxxxxxxxx, ganesh.venkatesan@xxxxxxxxx, jesse.brandeburg@xxxxxxxxx
In-reply-to: <20050621.133704.08321534.davem@davemloft.net>
References: <42A5284C.3060808@osdl.org> <1118147904.6320.108.camel@localhost.localdomain> <Pine.LNX.4.58.0506071351080.16594@tux.rsn.bth.se> <20050621.133704.08321534.davem@davemloft.net>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040124
David S. Miller wrote:
Also, e1000 sends full MTU sized SKBs down into the stack even if the
packet is very small.  This also hurts performance a lot.  As
discussed elsewhere, it should use a "small packet" cut-off just like
other drivers do.  If the RX frame is less than this cut-off value, a
new smaller sized SKB is allocated and the RX data copied into it.
The RX ring SKB is left in-place and given back to the chip.

Yes the copy is essentially free here as the data is already cached.

As a data point, I went the whole hog and used buffer recycling
in my essentially packet sniffing application. I.E. there are no
allocs per packet at all, and this make a HUGE difference. On a
2x3.4GHz 2xe1000 system I can receive 620Kpps per port sustained
into my userspace app which does a LOT of processing per packet.
Without the buffer recycling is was around 250Kpps.
Note I don't reuse an skb until the packet is copied into a
PACKET_MMAP buffer.

--
Pádraig Brady - http://www.pixelbeat.org
--

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