Eric Barton
2006-Nov-22 14:09 UTC
[Lustre-discuss] RE: portals/lnet as an abstraction over rdma and/or verbs
Dave,
I enjoyed chatting with you too - exciting stuff!
I''m afraid I''m completely schizophrenic about pushing LNET as
a general
purpose communications API.
My right brain says LNET is an ideal networking platform for all sorts of
high performance distributed applications running on inhomogeneous networks
with various support for RDMA.
But my left brain reminds me that making LNET a supported standard is kind
of at odds with the reason we forked it from Sandia Portals, which was to
allow its API to change according to lustre''s needs for a networking
abstraction. The introduction of further RAS, usability and scalability
features into lustre must inevitably affect all layers of the stack which
would make it a moving target for independent use.
I wonder if people on lustre-discuss has a view.
Cheers,
Eric
_____
From: Cohen, David (GTI) [mailto:d_cohen@ml.com]
Sent: 18 November 2006 7:01 PM
To: eeb@clusterfs.com
Cc: mkohari@novell.com; jim@pantasys.com; mike.heffner@evergrid.com;
bboas@systemfabricworks.com; rpearson@systemfabricworks.com
Subject: portals/lnet as an abstraction over rdma and/or verbs
Hi Eric,
It was great meeting you down in Tampa this past week. I really enjoyed your
presentation on lnet as well as talking about some of the interesting
challanges we face with our electronic trading business.
Am contacting you here as I am curious on the applicability of using lnet
independently of Lustre, basically as a general purpose messaging
abstraction over rdma and verbs. This could, for example, then be wrapped by
something like ATT''s sfio or be surfaced from within Java as an NIO
transport plug-in.
Such an approach would allow for leverage of the abstraction lnet provides
over independent transport mediums like myrinet, infiniband, 10 gbe, etc
while surfacing a reasonably simple channel/stream abstraction to higher
level applications. This would eliminate the need for something like SDP, as
an example.
Thanks in advance for your thoughts on this,
/dave.
_____
If you are not an intended recipient of this e-mail, please notify the
sender, delete it and do not read, act upon, print, disclose, copy, retain
or redistribute it. Click here <http://www.ml.com/email_terms/> for
important additional terms relating to this e-mail.
http://www.ml.com/email_terms/
_____
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mail.clusterfs.com/pipermail/lustre-discuss/attachments/20061122/2ce443e2/attachment.html
pauln
2006-Nov-22 14:51 UTC
[Lustre-discuss] RE: portals/lnet as an abstraction over rdma and/or verbs
I have a feeling that this will become a popular idea soon largely due flexibility provided by the efficient routing implementation. I''ve had similar ideas / feelings about using lnet apart from lustre. One of the obvious drawbacks is that the interesting LNDs require kernel mode execution to use them (I think this is still true??). As far as API changes, I''d suspect that lustre itself would be very sensitive to LNET changes. If user''s of LNET are no less sensitive than lustre itself then I think it could be useful to people. paul Eric Barton wrote:> Dave, > > I enjoyed chatting with you too - exciting stuff! > > I''m afraid I''m completely schizophrenic about pushing LNET as a > general purpose communications API. > > My right brain says LNET is an _ideal_ networking platform for all > sorts of high performance distributed applications running on > inhomogeneous networks with various support for RDMA. > > But my left brain reminds me that making LNET a supported standard is > kind of at odds with the reason we forked it from Sandia > Portals, which was to allow its API to change according to lustre''s > needs for a networking abstraction. The introduction of further RAS, > usability and scalability features into lustre must inevitably affect > all layers of the stack which would make it a moving target for > independent use. > > I wonder if people on lustre-discuss has a view. > > Cheers, > Eric > > ------------------------------------------------------------------------ > *From:* Cohen, David (GTI) [mailto:d_cohen@ml.com] > *Sent:* 18 November 2006 7:01 PM > *To:* eeb@clusterfs.com > *Cc:* mkohari@novell.com; jim@pantasys.com; > mike.heffner@evergrid.com; bboas@systemfabricworks.com; > rpearson@systemfabricworks.com > *Subject:* portals/lnet as an abstraction over rdma and/or verbs > > Hi Eric, > > It was great meeting you down in Tampa this past week. I really > enjoyed your presentation on lnet as well as talking about some of > the interesting challanges we face with our electronic trading > business. > > Am contacting you here as I am curious on the applicability of > using lnet independently of Lustre, basically as a general purpose > messaging abstraction over rdma and verbs. This could, for > example, then be wrapped by something like ATT''s sfio or be > surfaced from within Java as an NIO transport plug-in. > > Such an approach would allow for leverage of the abstraction lnet > provides over independent transport mediums like myrinet, > infiniband, 10 gbe, etc while surfacing a reasonably simple > channel/stream abstraction to higher level applications. This > would eliminate the need for something like SDP, as an example. > > Thanks in advance for your thoughts on this, > > /dave. > > ------------------------------------------------------------------------ > If you are not an intended recipient of this e-mail, please notify > the sender, delete it and do not read, act upon, print, disclose, > copy, retain or redistribute it. Click here > <http://www.ml.com/email_terms/>for important additional terms > relating to this e-mail. http://www.ml.com/email_terms/ > ------------------------------------------------------------------------ > >------------------------------------------------------------------------ > >_______________________________________________ >Lustre-discuss mailing list >Lustre-discuss@clusterfs.com >https://mail.clusterfs.com/mailman/listinfo/lustre-discuss > >