On 07/27/2015 11:24 AM, Jason Wang wrote:
On 07/24/2015 04:04 PM, Yang Hongyang wrote:
Hi Jason,
On 07/24/2015 10:12 AM, Jason Wang wrote:
On 07/24/2015 10:04 AM, Dong, Eddie wrote:
Hi Stefan:
Thanks for your comments!
On Mon, Jul 20, 2015 at 02:42:33PM +0800, Li Zhijian wrote:
We are planning to implement colo-proxy in qemu to cache and
compare
packets.
I thought there is a kernel module to do that?
Yes, that is the previous solution the COLO sub-community
choose
to go, but we realized it might be not the best choices, and
thus we
want to bring discussion back here :) More comments are welcome.
Hi:
Could you pls describe more details on this decision? What's the
reason
that you realize it was not the best choice?
Below is my opinion:
We realized that there're disadvantages do it in kernel spaces:
1. We need to recompile kernel: the colo-proxy kernel module is
implemented as a nf conntrack extension. Adding a extension
need to
modify the extension struct in-kernel, so recompile kernel is
needed.
There's no need to do all in kernel, you can use a separate process to
do the comparing and trigger the state sync through monitor.
I don't get it, colo-proxy kernel module using a kthread do the
comparing and
trigger the state sync. We implemented it as a nf conntrack extension
module,
so we need to extend the extension struct in-kernel, although it just
needs
few lines changes to kernel, but a recompile of kernel is needed.
Are you
talking about not implement it as a nf conntrack extension?