public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Roland Dreier <roland@topspincom.com>
To: linux-kernel@vger.kernel.org
Cc: Pete Zaitcev <zaitcev@redhat.com>
Subject: Re: Linux and system area networks
Date: 25 Jun 2001 15:55:20 -0700	[thread overview]
Message-ID: <52pubs5fvr.fsf@love-boat.topspincom.com> (raw)
In-Reply-To: <mailman.993492125.21454.linux-kernel2news@redhat.com> <200106252230.f5PMUDE26001@devserv.devel.redhat.com>
In-Reply-To: Pete Zaitcev's message of "Mon, 25 Jun 2001 18:30:13 -0400"

>>>>> "Pete" == Pete Zaitcev <zaitcev@redhat.com> writes:

    Roland> The rough idea is that WSD is a new user space library
    Roland> that looks at sockets calls and decides if they have to go
    Roland> through the usual kernel network stack, or if they can be
    Roland> handed off to a "SAN service provider" which bypasses the
    Roland> network stack and uses hardware reliable transport and
    Roland> possibly RDMA.

    Pete> That can be done in Linux just as easily, using same DLLs
    Pete> (they are called .so for "shared object"). If you look at
    Pete> Ashok Raj's Infi presentation, you may discern "user-level
    Pete> sockets", if you look hard enough. I invite you to try, if
    Pete> errors of others did not teach you anything.

I think you misunderstood the point.  Microsoft is providing this WSD
DLL as a standard part of W2K now.  This means that hardware vendors
just have to write a SAN service provider, and all Winsock-using
applications benefit transparently.  No matter how good your TCP/IP
implementation is, you still lose (especially in latency) compared to
using reliable hardware transport.  Oracle-with-VI and DAFS-vs-NFS
benchmarks show this quite clearly.

Linux has nothing to compare to Winsock Direct.  I agree, one could
put an equivalent in glibc, or one could take advantage of Linux's
relatively low system call latency and put something in the kernel.
The unfortunate consequence of this is that SAN (system area network)
hardware vendors are not going to support Linux very well.

BTW, do you have a pointer to Ashok Raj's presentation?

    Roland> This means that all applications that use Winsock benefit
    Roland> from the advanced network hardware.  Also, it means that
    Roland> Windows is much easier for hardware vendors to support
    Roland> than other OSes.  For example, Alacritech's TCP/IP offload
    Roland> NIC only works under Windows.  Microsoft is also including
    Roland> Infiniband support in Windows XP and Windows 2002.

    Pete> IMHO, Alacritech is about to join scores and scores of
    Pete> vendors who tried that before. Customers understand very
    Pete> soon that a properly written host based stack works much
    Pete> better in the face of a changing environment: Faster CPUs,
    Pete> new CPUs (IA-64), new network protocols (ECN). Besides, it
    Pete> is easy to "accelerate" a bad network stack, but try to
    Pete> outdo a well done stack.

OK, how about an Infiniband network with a TCP/IP gateway at the edge?
Have we thought about how Linux servers should use the gateway to talk
to internet hosts?  Surely there's no point in running TCP/IP inside
the Infiniband network, so there needs to be some concept of "socket
over Infiniband."

Thanks,
  Roland

  reply	other threads:[~2001-06-25 22:56 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.993492125.21454.linux-kernel2news@redhat.com>
2001-06-25 22:30 ` Linux and system area networks Pete Zaitcev
2001-06-25 22:55   ` Roland Dreier [this message]
2001-06-26  0:14     ` Alan Cox
2001-06-26  0:08   ` Alan Cox
2001-06-26 12:36 Jesse Pollard
2001-06-27 12:41 ` Pekka Pietikainen
2001-06-28 17:28   ` Bogdan Costescu
2001-06-28 19:12     ` Pekka Pietikainen
2001-06-28 21:46       ` Roland Dreier
2001-06-29  2:33         ` Bernd Eckenfels
  -- strict thread matches above, loose matches on Subject: below --
2001-06-25 17:59 Roland Dreier

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=52pubs5fvr.fsf@love-boat.topspincom.com \
    --to=roland@topspincom.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zaitcev@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox