I dont think so : a total of 52 bytes are pulled.
(20 bytes for IPv4 header, 32 bytes for TCP header (TS))
On Fri, Apr 19, 2013 at 11:07 AM, Markus Stockhausen
<markus.stockhau...@gmx.de> wrote:
>
>
> Am 17.04.13 21:10 schrieb "Eric Dumazet" unter <eduma...@google.com>:
>
>>Please try :
>>
>>diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
>>b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
>>index 2cfa76f..9bdff21 100644
>>--- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
>>+++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
>>@@ -112,6 +112,8 @@ static void ipoib_ud_skb_put_frags(struct
>>ipoib_dev_priv *priv,
>> if (ipoib_ud_need_sg(priv->max_ib_mtu)) {
>> skb_frag_t *frag = &skb_shinfo(skb)->frags[0];
>> unsigned int size;
>>+
>>+ prefetch(page_address(frag->page.p));
>> /*
>> * There is only two buffers needed for max_payload = 4K,
>> * first buf size is IPOIB_UD_HEAD_SIZE
>
> Thanks to both of you for spending time on this.
>
> Sorry to tell you that the above patch does not give any performance
> improvements. So I put a debug message inside inside pskb_may_pull()
> just in front of __pskb_pull_tail() to give an idea what happens.
>
> During a netserver/netperf run with an MTU of 2044 bytes I can read
> the following repeating messages:
>
> [ 52.909805] 0 bytes inline, 1988 bytes in fragment, pull 20 bytes
> [ 52.909807] 20 bytes inline, 1968 bytes in fragment, pull 40 bytes
> [ 52.909809] 40 bytes inline, 1948 bytes in fragment, pull 52 bytes
> [ 52.909812] 0 bytes inline, 1988 bytes in fragment, pull 20 bytes
> [ 52.909814] 20 bytes inline, 1968 bytes in fragment, pull 40 bytes
> [ 52.909816] 40 bytes inline, 1948 bytes in fragment, pull 52 bytes
>
>
> Now I'm getting lost somehow. From 2044 bytes 1988 are left in the
> fragment and 112 have to be pulled into the linear part. This is
> achieved by 3 steps. So we are far beyond the cache line size of 64
> bytes.
>
> Any ideas?
>
> Markus
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
