This pulls cannot explain a major performance problem.

Its a memcpy( ... 20 bytes). No more no less.

I have NICs here, reaching 20Gbp on a single TCP flow, were the pull is done.

Something else is going on.

On Fri, Apr 19, 2013 at 11:09 AM, Eric Dumazet <eduma...@google.com> wrote:
> 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

Reply via email to