Am 17.04.13 21:10 schrieb "Eric Dumazet" unter <[email protected]>:
>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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
