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

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

[Zhang Chen]

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(-)

-- 
2.7.4

[Qemu-devel] [PATCH 1/3] COLO-proxy: Add virtio-net packet parse function

[Zhang Chen]

Change parse_packet_early(Packet *pkt) to parse_packet_early(Packet *pkt, int offset)
that we can skip virtio-net header.

Signed-off-by: Zhang Chen <zhangchen.fnst@cn.fujitsu.com>
---
 net/colo-compare.c    | 11 +++++++----
 net/colo.c            |  8 ++++----
 net/colo.h            |  5 ++++-
 net/filter-rewriter.c | 15 ++++++++++-----
 4 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/net/colo-compare.c b/net/colo-compare.c
index 54e6d40..ce0cd12 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -126,10 +126,13 @@ static int packet_enqueue(CompareState *s, int mode)
         pkt = packet_new(s->sec_rs.buf, s->sec_rs.packet_len);
     }
 
-    if (parse_packet_early(pkt)) {
-        packet_destroy(pkt, NULL);
-        pkt = NULL;
-        return -1;
+    /* Try to parse the virtio-net-pci packet */
+    if (parse_packet_early(pkt, VIRTIO_NET_HEADER)) {
+        if (parse_packet_early(pkt, 0)) {
+            packet_destroy(pkt, NULL);
+            pkt = NULL;
+            return -1;
+        }
     }
     fill_connection_key(pkt, &key);
 
diff --git a/net/colo.c b/net/colo.c
index 8cc166b..060e822 100644
--- a/net/colo.c
+++ b/net/colo.c
@@ -39,15 +39,15 @@ int connection_key_equal(const void *key1, const void *key2)
     return memcmp(key1, key2, sizeof(ConnectionKey)) == 0;
 }
 
-int parse_packet_early(Packet *pkt)
+int parse_packet_early(Packet *pkt, int offset)
 {
     int network_length;
     static const uint8_t vlan[] = {0x81, 0x00};
-    uint8_t *data = pkt->data;
+    uint8_t *data = pkt->data + offset;
     uint16_t l3_proto;
     ssize_t l2hdr_len = eth_get_l2_hdr_length(data);
 
-    if (pkt->size < ETH_HLEN) {
+    if (pkt->size < ETH_HLEN + offset) {
         trace_colo_proxy_main("pkt->size < ETH_HLEN");
         return 1;
     }
@@ -73,7 +73,7 @@ int parse_packet_early(Packet *pkt)
     }
 
     network_length = pkt->ip->ip_hl * 4;
-    if (pkt->size < l2hdr_len + network_length) {
+    if (pkt->size < l2hdr_len + network_length + offset) {
         trace_colo_proxy_main("pkt->size < network_header + network_length");
         return 1;
     }
diff --git a/net/colo.h b/net/colo.h
index 7c524f3..b713f87 100644
--- a/net/colo.h
+++ b/net/colo.h
@@ -33,6 +33,9 @@
 #define IPPROTO_UDPLITE 136
 #endif
 
+/* virtio-net header length */
+#define VIRTIO_NET_HEADER 12
+
 typedef struct Packet {
     void *data;
     union {
@@ -73,7 +76,7 @@ typedef struct Connection {
 
 uint32_t connection_key_hash(const void *opaque);
 int connection_key_equal(const void *opaque1, const void *opaque2);
-int parse_packet_early(Packet *pkt);
+int parse_packet_early(Packet *pkt, int offset);
 void fill_connection_key(Packet *pkt, ConnectionKey *key);
 void reverse_connection_key(ConnectionKey *key);
 Connection *connection_new(ConnectionKey *key);
diff --git a/net/filter-rewriter.c b/net/filter-rewriter.c
index afa06e8..c3f0261 100644
--- a/net/filter-rewriter.c
+++ b/net/filter-rewriter.c
@@ -51,12 +51,17 @@ static void filter_rewriter_flush(NetFilterState *nf)
  */
 static int is_tcp_packet(Packet *pkt)
 {
-    if (!parse_packet_early(pkt) &&
-        pkt->ip->ip_p == IPPROTO_TCP) {
-        return 1;
-    } else {
-        return 0;
+    if (!parse_packet_early(pkt, VIRTIO_NET_HEADER) ||
+        !parse_packet_early(pkt, 0)) {
+        if (pkt->ip->ip_p == IPPROTO_TCP) {
+            return 1;
+        } else {
+            goto out;
+        }
     }
+
+out:
+    return 0;
 }
 
 /* handle tcp packet from primary guest */
-- 
2.7.4

[Qemu-devel] [PATCH 2/3] COLO-proxy: Add a tag to mark virtio-net packet

[Zhang Chen]

Add this tag that compare can recognize virtio-net packet.

Signed-off-by: Zhang Chen <zhangchen.fnst@cn.fujitsu.com>
---
 net/colo.c | 6 ++++++
 net/colo.h | 2 ++
 2 files changed, 8 insertions(+)

diff --git a/net/colo.c b/net/colo.c
index 060e822..d2b3683 100644
--- a/net/colo.c
+++ b/net/colo.c
@@ -79,6 +79,12 @@ int parse_packet_early(Packet *pkt, int offset)
     }
     pkt->transport_header = pkt->network_header + network_length;
 
+    if (offset == VIRTIO_NET_HEADER) {
+        pkt->is_virtio_net_pkt = true;
+    } else {
+        pkt->is_virtio_net_pkt = false;
+    }
+
     return 0;
 }
 
diff --git a/net/colo.h b/net/colo.h
index b713f87..535793d 100644
--- a/net/colo.h
+++ b/net/colo.h
@@ -46,6 +46,8 @@ typedef struct Packet {
     int size;
     /* Time of packet creation, in wall clock ms */
     int64_t creation_ms;
+    /* Mark this packet as a virtio net packet or not */
+    bool is_virtio_net_pkt;
 } Packet;
 
 typedef struct ConnectionKey {
-- 
2.7.4

[Qemu-devel] [PATCH 3/3] COLO-compare: Add virtio-net packet compare support

[Zhang Chen]

If packet is virtio-net packet we will skip the virtio-net header
compare packet's payload.

Signed-off-by: Zhang Chen <zhangchen.fnst@cn.fujitsu.com>
---
 net/colo-compare.c | 31 ++++++++++++++++++++++++++-----
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/net/colo-compare.c b/net/colo-compare.c
index ce0cd12..34af11a 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -237,7 +237,12 @@ static int colo_packet_compare_tcp(Packet *spkt, Packet *ppkt)
     }
 
     if (ptcp->th_sum == stcp->th_sum) {
-        res = colo_packet_compare_common(ppkt, spkt, ETH_HLEN);
+        if (ppkt->is_virtio_net_pkt) {
+            res = colo_packet_compare_common(ppkt, spkt, ETH_HLEN
+                                             + VIRTIO_NET_HEADER);
+        } else {
+            res = colo_packet_compare_common(ppkt, spkt, ETH_HLEN);
+        }
     } else {
         res = -1;
     }
@@ -285,8 +290,14 @@ static int colo_packet_compare_udp(Packet *spkt, Packet *ppkt)
      * other field like TOS,TTL,IP Checksum. we only need to compare
      * the ip payload here.
      */
-    ret = colo_packet_compare_common(ppkt, spkt,
-                                     network_header_length + ETH_HLEN);
+    if (ppkt->is_virtio_net_pkt) {
+        ret = colo_packet_compare_common(ppkt, spkt,
+                                         network_header_length
+                                         + VIRTIO_NET_HEADER + ETH_HLEN);
+    } else {
+        ret = colo_packet_compare_common(ppkt, spkt,
+                                         network_header_length + ETH_HLEN);
+    }
 
     if (ret) {
         trace_colo_compare_udp_miscompare("primary pkt size", ppkt->size);
@@ -309,6 +320,7 @@ static int colo_packet_compare_udp(Packet *spkt, Packet *ppkt)
 static int colo_packet_compare_icmp(Packet *spkt, Packet *ppkt)
 {
     int network_header_length = ppkt->ip->ip_hl * 4;
+    int ret;
 
     trace_colo_compare_main("compare icmp");
 
@@ -322,8 +334,17 @@ static int colo_packet_compare_icmp(Packet *spkt, Packet *ppkt)
      * other field like TOS,TTL,IP Checksum. we only need to compare
      * the ip payload here.
      */
-    if (colo_packet_compare_common(ppkt, spkt,
-                                   network_header_length + ETH_HLEN)) {
+
+    if (ppkt->is_virtio_net_pkt) {
+        ret = colo_packet_compare_common(ppkt, spkt,
+                                         network_header_length
+                                         + VIRTIO_NET_HEADER + ETH_HLEN);
+    } else {
+        ret = colo_packet_compare_common(ppkt, spkt,
+                                         network_header_length + ETH_HLEN);
+    }
+
+    if (ret) {
         trace_colo_compare_icmp_miscompare("primary pkt size",
                                            ppkt->size);
         trace_colo_compare_icmp_miscompare("Secondary pkt size",
-- 
2.7.4

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

[Jason Wang]

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(-)
>

Hi:

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.

Thanks

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

[Zhang Chen]

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(-)
>>
>
> Hi:
>
> 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 ?

Thanks
Zhang Chen

> Thanks
>
>
>

-- 
Thanks
Zhang Chen

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

[Jason Wang]

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(-)
>>>
>>
>> Hi:
>>
>> 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.

Thanks

>
> Thanks
> Zhang Chen
>
>> Thanks
>>
>>
>>
>

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

[Zhang Chen]

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(-)
>>>>
>>>
>>> Hi:
>>>
>>> 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?

Thanks
Zhang Chen

>
> Thanks
>
>>
>> Thanks
>> Zhang Chen
>>
>>> Thanks
>>>
>>>
>>>
>>
>
>
>
> .
>

-- 
Thanks
Zhang Chen

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

[Jason Wang]

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(-)
>>>>>
>>>>
>>>> Hi:
>>>>
>>>> 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?

Thanks

>
> Thanks
> Zhang Chen

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

[Zhang Chen]

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(-)
>>>>>>
>>>>>
>>>>> Hi:
>>>>>
>>>>> 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?
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?
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?

Thanks
Zhang Chen



> Thanks
>
>>
>> Thanks
>> Zhang Chen
>
>
>
> .
>

-- 
Thanks
Zhang Chen

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

[Jason Wang]

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(-)
>>>>>>>
>>>>>>
>>>>>> Hi:
>>>>>>
>>>>>> 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?
>
> Thanks
> 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?

Thanks

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

[Zhang Chen]

On 03/21/2017 05:15 PM, Jason Wang wrote:
>
>
> 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(-)
>>>>>>>>
>>>>>>>
>>>>>>> Hi:
>>>>>>>
>>>>>>> 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?
>>
>> Thanks
>> 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?

Yes, encoding is OK in filter, but decoding we must touch the 
"net_fill_rstate()", net/socket.c also use this
function to receive packet, other codes try to send packet like struct 
{int size; const uint8_t buf[];} maybe conflict with it.
For the vnet header length do this job is acceptable? and in what 
situation the vnet header length will be change?

Thanks
Zhang Chen

>
> Thanks
>
>
>
> .
>

-- 
Thanks
Zhang Chen

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

[Jason Wang]

On 2017年03月22日 09:50, Zhang Chen wrote:
>
>
> On 03/21/2017 05:15 PM, Jason Wang wrote:
>>
>>
>> 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(-)
>>>>>>>>>
>>>>>>>>
>>>>>>>> Hi:
>>>>>>>>
>>>>>>>> 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?
>>>
>>> Thanks
>>> 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?
>
> Yes, encoding is OK in filter, but decoding we must touch the 
> "net_fill_rstate()", net/socket.c also use this
> function to receive packet, other codes try to send packet like struct 
> {int size; const uint8_t buf[];} maybe conflict with it.
> For the vnet header length do this job is acceptable?

Yes, I think so.

> and in what situation the vnet header length will be change?

If guest support mrg_rxbuf or virtio 1.0, there will be 2 more bytes 
(__virtio16 num_buffers). And we plan to add more information in the 
header in the future.

Thanks

>
> Thanks
> Zhang Chen

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

[Zhang Chen]

On 03/22/2017 11:13 AM, Jason Wang wrote:
>
>
> On 2017年03月22日 09:50, Zhang Chen wrote:
>>
>>
>> On 03/21/2017 05:15 PM, Jason Wang wrote:
>>>
>>>
>>> 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(-)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi:
>>>>>>>>>
>>>>>>>>> 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?
>>>>
>>>> Thanks
>>>> 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?
>>
>> Yes, encoding is OK in filter, but decoding we must touch the 
>> "net_fill_rstate()", net/socket.c also use this
>> function to receive packet, other codes try to send packet like 
>> struct {int size; const uint8_t buf[];} maybe conflict with it.
>> For the vnet header length do this job is acceptable?
>
> Yes, I think so.
>
>> and in what situation the vnet header length will be change?
>
> If guest support mrg_rxbuf or virtio 1.0, there will be 2 more bytes 
> (__virtio16 num_buffers). And we plan to add more information in the 
> header in the future.
>

OK~ I got your point, will add related codes in next version.

Thanks
Zhang Chen

> Thanks
>
>>
>> Thanks
>> Zhang Chen
>
>
>
>
> .
>

-- 
Thanks
Zhang Chen