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)) {
+
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 possibilites for TCP optimization (davem), driver common copbreak
etc.
10 matches
Mail list logo
