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