Benjamin LaHaise writes:
> Right. Btw, looking over your changes for skb reuse and how the e1000
> lays out its data structures, I think there is still some room for
> improvement: currently you still touch the skb that the e1000 used to
> allocate the receive buffers in. That cacheline
jamal writes:
> > Here we process (drop) about 13% packets more when skb'a get reued.
> >
> Very cool.
> Robert, it would be interesting to see something more interesting
> (longer code path) such as udp. You can still use a packetgen to shoot
> at the box (netperf is a wimp), send it to
On Tue, Jan 24, 2006 at 10:35:06PM +0100, Robert Olsson wrote:
> I splitted alloc_skb in two parts to get the memset() part even done
> in the driver just before passing the skb to the stack.
>
> I did expect a big win in but I didn't see any gain. Strange but the code
> was bad so it might
On Tue, 2006-24-01 at 14:23 +0100, Robert Olsson wrote:
> Hello!
> We disussed the resue of skb's some time ago.
>
> Below some code to examine how skb's can be reused if upper layer (RX
> softirq)
> can consume the skb so we with in NAPI path can detect and reuse the skb. It
> can give new po
Benjamin LaHaise writes:
> Instead of doing a completely separate skb reuse path, what happens if
> you remove the memset() from __alloc_skb() and instead do it in a slab
> ctor? I remember seeing that in the profiles for af_unix. Dave, could
> you refresh my memory why the slab ctor end
From: Benjamin LaHaise <[EMAIL PROTECTED]>
Date: Tue, 24 Jan 2006 15:58:27 -0500
> Instead of doing a completely separate skb reuse path, what happens if
> you remove the memset() from __alloc_skb() and instead do it in a slab
> ctor? I remember seeing that in the profiles for af_unix. Dave, c
On Tue, Jan 24, 2006 at 02:23:15PM +0100, Robert Olsson wrote:
> etc. In the test below I use my usual lab setup but just let netfilter
> drop the packets. We win about 13% in this experiment below.
>
> Here we process (drop) about 13% packets more when skb'a get reued.
Instead of doing a comple
From: Ben Greear <[EMAIL PROTECTED]>
Date: Tue, 24 Jan 2006 12:25:21 -0800
> That 16 is probably the same bug as broke pktgen for chelsio NICs.
> Shouldn't we take the netdev->hard_header_len into account??
Ben, this code is in the e1000 driver... don't be rediculious :)
-
To unsubscribe from thi
Robert Olsson wrote:
+ /*
+ * If skb is consumed by RX softirq we can simply use it again
+ * otherwise undo the users increment with kfree
+*/
+
+ if (!multi_descriptor && atomic_read(&skb->users) == 1 &&
+ realloc_skb(skb, adapter->rx_buffer_len, GFP_ATOMIC)) {
+
