[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1395115400.9114.26.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Mon, 17 Mar 2014 21:03:20 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Zheng Liu <gnehzuil.liu@...il.com>
Cc: Hannes Frederic Sowa <hannes@...essinduktion.org>,
netdev <netdev@...r.kernel.org>, Li Yu <bingtian.ly@...bao.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Bruce Brutus Curtis <brutus@...gle.com>,
Weiping Pan <panweiping3@...il.com>, tmorvai@...il.com
Subject: Re: What's the status of TCP friends?
On Tue, 2014-03-18 at 11:13 +0800, Zheng Liu wrote:
> That sounds great! But it might not satisfy our requirement. If we use
> AF_UNIX our program will not be deployed on two servers. Meanwhile
> AF_INET has been applied in our program to communicate with other
> clients. So DGRAM seems that it is not a good idea. Now our program
> needs a IPC mechansim that can commnucate between two servers and
> provide a high performance when two processes are run on the same
> server. That is the reason why I am interested in TCP friends. :)
TCP friends is another layer added into TCP stack, for what ?
Improving performance for lazy applications ?
Really, if you cared about performance, you would have added a way to
use fast IPC if available.
TCP friends will still be slower than the available IPC mechanisms, by
an order of magnitude.
So instead of spending time on this TCP friends dream, I think you
should focus on existing and supported mechanisms.
I for example could add zerocopy support to AF_UNIX, if you think its
worth it.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists