From: tgh <wwwwww4187@sina.com.cn>
To: kangho kim <sunnykuz@gmail.com>,
Mark Williamson <mark.williamson@cl.cam.ac.uk>,
Suzanne McIntosh <skranjac@us.ibm.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [RFC] Lightweight socket communication between domainsin a single machine
Date: Wed, 31 Oct 2007 17:54:29 +0800 [thread overview]
Message-ID: <472850D5.90202@sina.com.cn> (raw)
In-Reply-To: <591c7e8a0705132344u7af1b9a2hb713319fae245f02@mail.gmail.com>
hi
xensocket and xway, what are the differences between them ,in the
mechanism ,functionality ,or performance ,etc..?
and what about the xen interdomain communication mechanism ?and are xway
or xensocket or some mixed thing or something else adopted into the xen
or not ?
Thanks in advance
kangho kim 写道:
> Hi, there.
> 2007/5/8, Mark Williamson <mark.williamson@cl.cam.ac.uk
> <mailto:mark.williamson@cl.cam.ac.uk>>:
>
> Hi there,
>
> > I attached a PPT file that has some note on the implementation,
> comparing
> > to XenSocket.
> > In each slide of the PPT, I wrote a few lines of slide note.
> Please read
> > the note for more details.
>
> So, to summarise, the main points of your approach are:
>
> 1) shared memory data transfers for streams of data - effectively a
> Xen "device" channel per stream
> 2) use existing TCP syscall interface and protocol code to handle
> connection
> setup and teardown (+ calls into additional setup / teardown code
> for Xway
> itself, of course)
>
> 3) allow TCP-oriented applications to leverage Xway without any
> modification
> whatsoever, using the same API as usual
>
>
> It looks like a nice side effect of your strategy of leveraging
> TCP is that
> you could perhaps modify your "Xway switch" to plumb the data
> stream either
> through the TCP stack, or the Xway shared memory at will -
> allowing you to
> fall back to TCP when migrating off a host, and allowing you to
> transparently
> switch to Xway when migrating to be colocated with the server
> you're talking
> to.
>
> I agree with you that fortunately, it's easy for Xway to adjust the
> migration though we didn't consider the migration when designing it.
> The key point that Xway need to deal with for the migration is how
> Xway in each domain in a communication channel become aware that your
> domain or the peer domain is migrated. Once Xway detects the
> migration, the rest is simple as you commented.
>
> You seem to get some impressive throughput numbers when working on
> shared
> memory ;-) Do you think there are any further optimisations that
> you could
> do here?
>
> In the current design & implementation, Xway sends user data to the
> peer whenever user calls send request. The naive send machanism can be
> improved, so that we could expect higher bandwidth than the current.
> We have no idea above this improvement by now.
>
> I'm curious as to how you handle addressing... Is an
> IP-address->local domain
> id lookup process happening somewhere? How does this work? Can any
> TCP
> connection take advantage of Xway, or is some advance
> configuration required?
>
> Xway maintains only IP addresses of domains that are in the same host,
> but does not IP-address->local domain id mapping. To know how Xway
> handles addressing, you need to know what is going on when a
> connection is established. I'll show you the detail steps concerning
> the connection establishment.
> Suppose domains, D1 and D2 are in the same host, and socket
> application A1 in D1 attempts to connect socket appliation A2 in D2.
> Xway executes following tasks:
> 1) creates TCP session, C1, as if there were no Xway.
> 2) detects that the peer in the connection is in the same host by
> referencing IP address table in the current implementation.
> 3) creates another TCP session, C2, between Xway in D1 and the helper
> daemon living in D2. C2 is supposed to bypass Xway module.
> 4) sends to D2 through C2, domain id of D1, grant references of shared
> memory and port number of event channel that D1 created.
> 4) receives from D2 through C2, domain id of D2, grant references of
> shared memory that D2 ceated.
> 5) creates Xway session which will be bound to C1, with the initial
> setup information.
> 6) destroys C2.
> As you see in the steps above, Xway in D1 sends its domain id to D2,
> and become to know domain id of peer by querying the helper daemon in
> D2. This is IP-address->domain id lookup process that you want to know
> I guess.
>
> > Since I don't know much about XenSocket I comapred only a few
> features that
> > I'm interested in.
>
> Perhaps the XenSocket folks can comment more on this. It would be
> good to
> identify how much commonality in code / purpose there are between
> the two
> projects.
>
> > I know that this summary slide is not enough to understand the
> whole things
> > of Xway.
> > However, let's start discussion on Xway as well as XenSocket.
>
> --
> Dave: Just a question. What use is a unicyle with no seat? And no
> pedals!
> Mark: To answer a question with a question: What use is a skateboard?
> Dave: Skateboards have wheels.
> Mark: My wheel has a wheel!
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
next prev parent reply other threads:[~2007-10-31 9:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-01 5:58 [RFC] Lightweight socket communication between domains in a single machine 김강호
2007-05-01 9:12 ` [RFC] Lightweight socket communication between domainsin " Ian Pratt
2007-05-02 9:10 ` 김강호
2007-05-07 18:56 ` Mark Williamson
2007-05-14 6:44 ` kangho kim
2007-10-31 9:54 ` tgh [this message]
2007-05-03 2:10 ` 김강호
2007-05-09 13:44 ` Zhu Han
2007-05-10 6:04 ` kangho kim
2007-05-10 10:35 ` Mark Williamson
-- strict thread matches above, loose matches on Subject: below --
2007-05-11 14:07 Suzanne McIntosh
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=472850D5.90202@sina.com.cn \
--to=wwwwww4187@sina.com.cn \
--cc=mark.williamson@cl.cam.ac.uk \
--cc=skranjac@us.ibm.com \
--cc=sunnykuz@gmail.com \
--cc=xen-devel@lists.xensource.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 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.