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