[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/3] Add COLO-proxy virtio-net support

From: Jason Wang
Subject: Re: [Qemu-devel] [PATCH 0/3] Add COLO-proxy virtio-net support
Date: Tue, 21 Mar 2017 17:15:10 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

On 2017年03月21日 15:08, Zhang Chen wrote:

On 03/21/2017 02:30 PM, Jason Wang wrote:

On 2017年03月21日 14:16, Zhang Chen wrote:

On 03/21/2017 02:10 PM, Jason Wang wrote:

On 2017年03月21日 13:47, Zhang Chen wrote:

On 03/21/2017 11:39 AM, Jason Wang wrote:

On 2017年03月16日 17:52, Zhang Chen wrote:
If user use -device virtio-net-pci, virtio-net driver will add a header
to raw net packet that colo-proxy can't handle it. COLO-proxy just
focus on the packet payload, so we skip the virtio-net header to compare
the sent packet that primary guest's to secondary guest's.

Zhang Chen (3):
   COLO-proxy: Add virtio-net packet parse function
   COLO-proxy: Add a tag to mark virtio-net packet
   COLO-compare: Add virtio-net packet compare support

net/colo-compare.c | 42 +++++++++++++++++++++++++++++++++---------
  net/colo.c            | 14 ++++++++++----
  net/colo.h            |  7 ++++++-
  net/filter-rewriter.c | 15 ++++++++++-----
  4 files changed, 59 insertions(+), 19 deletions(-)


Git grep told us virtio-net is not the only user for vnet header. E1000e and vmxnet3 uses it too.

So we need solve them all instead of being virtio-net specific.

Yes, In this series I just try to parse vnet header, if failed I will try to parse normal net packet.
So, I just focus on vnet header rather than virtio-net driver.
But the patch comments really make people confused , Should I fix all the comments send the V2 ?

Yes, please. Beside this, instead of using fixed vnet header len macro, you should query the backend for the length of vnet header.

I want query the backend too, but colo-compare is not a netfilter means it no need attach any netdev.
How can we query the backend for the length of vnet header?

Filters can know this, then how about let filters add the vnet header length before the real packet and send it to colo-compare?

I don't know whether I understand your comments...
Do you means filter send a vnet header length firstly(independent length packet), then send the real packet?

This requires too much changes and may break the compatibility of socket net backend.

If yes, I think it so expensive, in colo we use filter mirror or redirect packet between primary and secondary
that no need to know the vnet header length.
Or do you means add a fake vnet header to real packet in same one packet?

Kind of, see below.

If yes, filter-mirror and filter-redirector must touch the packet do some job like colo-compare. We initial design split colo-proxy to 4 modules have make filter-mirror and filter-redirector not to touch the packet content, colo-compare and filter-rewriter do the packet data related job.
Or you have other way to tell colo-compare the length?

Zhang Chen

I mean e.g: We send a packet like struct {int size; const uint8_t buf[];} currently. We can try to add vnet header information like {int size; int vnet_hdr_len; const uint8_t buf[];}. Or even just pack the vnet_hdr_len information to the higher bits of size. Then we just need some encoding and decoding and the changes were limited.

Does this make sense?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]