[Top] [All Lists]

Re: RFC: NAPI packet weighting patch

To: Eric Dumazet <dada1@xxxxxxxxxxxxx>
Subject: Re: RFC: NAPI packet weighting patch
From: Eric Dumazet <dada1@xxxxxxxxxxxxx>
Date: Thu, 23 Jun 2005 00:13:21 +0200
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, ak@xxxxxxx, leonid.grossman@xxxxxxxxxxxx, hadi@xxxxxxxxxx, becker@xxxxxxxxx, rick.jones2@xxxxxx, netdev@xxxxxxxxxxx, davem@xxxxxxxxxx
In-reply-to: <42B9DA4D.5090103@xxxxxxxxxxxxx>
References: <1119458226.6918.142.camel@xxxxxxxxxxxxxxxxxxxxx> <200506221801.j5MI11xS021866@xxxxxxxxxxxxxxxxx> <20050622180654.GX14251@xxxxxxxxxxxxx> <20050622.132241.21929037.davem@xxxxxxxxxxxxx> <42B9DA4D.5090103@xxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)
Eric Dumazet a écrit :

Then maybe we could also play with prefetchw() in the case the incoming frame
is small enough to be copied to a new skb.


    copy_skb = dev_alloc_skb(len + 2);
    if (copy_skb == NULL)
        goto drop_it_no_recycle;
+    prefetchw(copy_skb->data);

    copy_skb->dev = tp->dev;
    skb_reserve(copy_skb, 2);
    skb_put(copy_skb, len);

I also found that the memcpy() done to copy the data to the new skb suffers 
from misalignment.

This is because of skb_reserve(skbs, 2) that was done on both skb, and memcpy() (at least on x86_64) doing long word copies without checking alignment of source or destination.

Maybe we could :

1) make sure both skbs had the same skb_reserve() of 2 (thats not clear because 
tg3.c mixes the '2' and tp->rx_offset,
and according to a comment :
rx_offset != 2 iff this is a 5701 card running in PCI-X mode

2) and do :

-       memcpy(copy_skb->data, skb->data, len);
+       memcpy(copy_skb->data-2, skb->data-2, len+2);

(That is copy 2 more bytes, but gain aligned copy to speedup memcpy())

Eric Dumazet

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