All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pradeep Satyanarayana <pradeeps-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
To: "Hefty, Sean" <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	kashyapv-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org,
	sri-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org
Subject: rsockets and other performance
Date: Thu, 14 Jun 2012 08:24:35 -0700	[thread overview]
Message-ID: <4FDA0233.6090409@linux.vnet.ibm.com> (raw)

Traditional sockets based applications wanting high throughput could use 
rsockets Since it is layered on top of uverbs we expected to see good 
throughput numbers.
So, we started to run netperf and iperf. We observed that it tops off at 
about 20Gb/s with QDR adapters. A quick "perf top" revealed a lot of 
cycles spent in memcpy().
We had hoped these numbers would be somewhat higher since we did not 
expect the memcpy() to have such a large overhead.

Given the copy overhead, we wanted to revisit the IPoIB and SDP 
performance. Hence we installed to OFED-1.5.4.1 on RHEL 6.2. We found 
that for small packets SDP starts
with low throughputs, but seems to catch up with rsockets at about 16 KB 
packets. On the other hand IPoIB CM tops off at about 10 Gb/s.

Since SDP does in kernel RDMA we expected IPoIB CM and SDP numbers to be 
much closer. Again "perf top" revealed that IPoIB was spending a large 
number of cycles in
checksum computation. Out of curiosity Sridhar made the following changes:

--- ipoib_cm.c.orig    2012-06-10 15:27:10.589325138 -0400
+++ ipoib_cm.c    2012-06-12 11:29:49.073262516 -0400
@@ -670,6 +670,7 @@ copied:
      skb->dev = dev;
      /* XXX get correct PACKET_ type here */
      skb->pkt_type = PACKET_HOST;
+    skb->ip_summed = CHECKSUM_UNNECESSARY;
      netif_receive_skb(skb);

@@ -1464,7 +1464,8 @@ static ssize_t set_mode(struct device *d
                 "will cause multicast packet drops\n");

          rtnl_lock();
-        dev->features &= ~(NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_TSO);
+        dev->features &= ~(NETIF_F_SG | NETIF_F_TSO);
          priv->tx_wr.send_flags &= ~IB_SEND_IP_CSUM;

          if (ipoib_cm_max_mtu(dev) > priv->mcast_mtu)


With these minimal changes IPoIB throughput reached between 19-20Gb/s 
with just 2 threads. This was really unexpected. Given that, we wanted 
to revisit the usage of checksums in IPoIB.
So, it looks worthwhile to allow for 'checksum-less' IPoIB-CM within a 
cluster on a single subnet. From a checksum perspective, this would be 
no different from RDMA. What are your thoughts?

Thanks
Pradeep

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

             reply	other threads:[~2012-06-14 15:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-14 15:24 Pradeep Satyanarayana [this message]
     [not found] ` <4FDA0233.6090409-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2012-06-14 16:02   ` rsockets and other performance Hefty, Sean
2012-06-14 16:09   ` Sridhar Samudrala
     [not found]     ` <1339690194.14317.5.camel-5vSEHtyIv2TJ4MwkZ4db91aTQe2KTcn/@public.gmane.org>
2012-06-17  7:22       ` Or Gerlitz
     [not found]         ` <4FDD85B3.2090406-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2012-06-17 21:20           ` Pradeep Satyanarayana
2012-06-14 17:22   ` Jason Gunthorpe
     [not found]     ` <20120614172245.GC6552-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2012-06-15  6:48       ` Vivek Kashyap
     [not found]         ` <alpine.LRH.2.00.1206142336220.13728-Nzfcc2Us4m+Xfo/+vza+31aTQe2KTcn/@public.gmane.org>
2012-06-15 17:19           ` Jason Gunthorpe
     [not found]             ` <20120615171919.GA17224-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2012-06-18  6:37               ` Vivek Kashyap
     [not found]                 ` <alpine.LRH.2.00.1206172330220.13728-Nzfcc2Us4m+Xfo/+vza+31aTQe2KTcn/@public.gmane.org>
2012-06-18 17:53                   ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FDA0233.6090409@linux.vnet.ibm.com \
    --to=pradeeps-23vcf4htsmix0ybbhkvfkdbpr1lh4cv8@public.gmane.org \
    --cc=kashyapv-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=sri-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.