qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 2/3] Unified Datagram Socket Transport - GRE sup


From: Anton Ivanov
Subject: Re: [Qemu-devel] [PATCH 2/3] Unified Datagram Socket Transport - GRE support
Date: Wed, 19 Jul 2017 18:32:08 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0



On 19/07/17 15:40, Eric Blake wrote:
On 07/18/2017 12:08 PM, address@hidden wrote:
From: Anton Ivanov <address@hidden>

This adds GRETAP support to the unified socket driver.

Signed-off-by: Anton Ivanov <address@hidden>
---
  net/Makefile.objs |   2 +-
  net/clients.h     |   4 +
  net/gre.c         | 313 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
  net/net.c         |   5 +
  qapi-schema.json  |  46 +++++++-
  qemu-options.hx   |  63 ++++++++++-
  6 files changed, 425 insertions(+), 8 deletions(-)
  create mode 100644 net/gre.c

Just an interface review:

+++ b/qapi-schema.json
@@ -3847,7 +3847,41 @@
      'txsession':    'uint32',
      '*rxsession':   'uint32',
      '*offset':      'uint32' } }
-
+##
+# @NetdevGREOptions:
+#
+# Connect the VLAN to Ethernet over Ethernet over GRE (GRETAP) tunnel
+#
+# @src: source address
+#
+# @dst: destination address
+#
+# @ipv6: force the use of ipv6
This doesn't quite match what we do with other sockets (where we have
both ipv4 and ipv6 booleans to allow IPv4-only, IPv6-only, or both).  Is
this something where we can reuse InetSocketAddress instead of inventing
yet another way of doing things?

Then again, it does match what NetdevL2TPv3Options did :(

I just reviewed this again.

I do not think  we can today. This is the declaration:

##
{ 'struct': 'InetSocketAddressBase',
  'data': {
    'host': 'str',
    'port': 'str' } }

##

If I read this right port is mandatory, correct?

We may be able to do it if the port portion if InetSocketAddress becomes optional. There is no such thing as port for the protocols which use the raw families.

I now recall it being the reason why L2TPv3 does it this way.

I am addressing the rest of the comments in the meantime.

A.

[snip]

--
Anton R. Ivanov

Cambridge Greys Limited, England and Wales company No 10273661
http://www.cambridgegreys.com/




reply via email to

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