On 22/05/2019 14:46, Johannes Berg wrote:
Hi Anton,
I'm thinking about adding virt-io support to UML, but the tricky part is
that while I want to use the virt-io basics (because it's a nice
interface from the 'inside'), I don't actually want the stock drivers
that are part of the kernel now
On 22/05/2019 14:02, Johannes Berg wrote:
Hi,
While my main interest is mostly in UML right now [1] I've CC'ed the
qemu and virtualization lists because something similar might actually
apply to other types of virtualization.
I'm thinking about adding virt-io support to UML, but the tricky p
On 24/07/17 05:03, Jason Wang wrote:
>
>
> On 2017年07月22日 02:50, Anton Ivanov wrote:
>>
>> [snip]
>>
>>>> +"-netdev raw,id=str,ifname=ifname\n"
>>>> +"configure a network backend with ID 'str'
That is an option as well.
I am travelling this week and will get back to this first thing next week.
A.
On 24 July 2017 05:17:25 CEST, Jason Wang wrote:
>
>
>On 2017年07月21日 12:25, Anton Ivanov wrote:
>>
>>
>> On 21/07/17 04:55, Jason Wang wrote:
>>>
>
##
If I read this right port is mandatory, correct?
Okay, so it sounds like reusing InetSocket directly may not be possible.
But there's still the interface question of whether we want dual 'ipv4'
and 'ipv6' switches to allow finer-grain control over which (or both)
families to be used.
I
Hi Jason, Hi Eric, hi list,
I have gone through all comments and addressed everything to which I did
not reply separately with clarifications.
Before I resubmit I have a couple of architectural questions:
1. Is it OK in its current form: UDST client which cannot be
instantiated and the other
[snip]
+"-netdev raw,id=str,ifname=ifname\n"
+"configure a network backend with ID 'str'
connected to\n"
+"an Ethernet interface named ifname via raw
socket.\n"
+"This backend does not change the interface
settings.\n"
+"
[snip]
+NetUnifiedState *s = (NetUnifiedState *) us;
+L2TPV3TunnelParams *p = (L2TPV3TunnelParams *) s->params;
How about embedding NetUnifiedState into this structure and keep using
NetL2TPV3State? Then:
- 's' could be kept and lots of lines of changes could be saved here
and l2t
On 21/07/17 04:55, Jason Wang wrote:
On 2017年07月21日 03:12, anton.iva...@cambridgegreys.com wrote:
Hi all,
This addresses comments so far except Eric's suggestion to use
InetSocketAddressBase. If I understand correctly its intended use,
it will not be of help for protocols which have no port
From: Anton Ivanov
Raw Socket Backend for Universal Datagram Socket Transport
Signed-off-by: Anton Ivanov
---
net/Makefile.objs | 2 +-
net/clients.h | 3 ++
net/net.c | 1 +
net/raw.c | 123 ++
qapi-schema.json
From: Anton Ivanov
Migrate datagram operation to UDST if UDST is available.
Signed-off-by: Anton Ivanov
---
net/socket.c | 123 ---
1 file changed, 118 insertions(+), 5 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index
From: Anton Ivanov
GRETAP Backend for Universal Datagram Socket Transport
Signed-off-by: Anton Ivanov
---
net/Makefile.objs | 2 +-
net/clients.h | 4 +
net/gre.c | 340 ++
net/net.c | 1 +
qapi-schema.json | 50
From: Anton Ivanov
Basic infrastructure to start moving datagram based transports
to a common infrastructure as well as introduce several
additional transports.
Signed-off-by: Anton Ivanov
---
configure | 12 +-
net/Makefile.objs | 2 +-
net/net.c | 4 +-
net/udst.c
Hi all,
This addresses comments so far except Eric's suggestion to use
InetSocketAddressBase. If I understand correctly its intended use,
it will not be of help for protocols which have no port (raw
sockets - GRE, L2TPv3, etc).
It also includes a port of the original socket.c transport to
the new
From: Anton Ivanov
1. Migrate L2TPv3 transport to the Unified Datagram Socket
Transport Backend.
2. Make v4/v6 behaviour identical to all other transports
Signed-off-by: Anton Ivanov
---
net/l2tpv3.c | 566 +++
qapi-schema.json | 1
From: Anton Ivanov
GRETAP Backend for Universal Datagram Socket Transport
Signed-off-by: Anton Ivanov
---
net/Makefile.objs | 2 +-
net/clients.h | 4 +
net/gre.c | 311 ++
net/net.c | 1 +
qapi-schema.json | 41
From: Anton Ivanov
Raw Socket Backend for Universal Datagram Socket Transport
Signed-off-by: Anton Ivanov
---
net/Makefile.objs | 2 +-
net/clients.h | 3 ++
net/net.c | 1 +
net/raw.c | 123 ++
qapi-schema.json
From: Anton Ivanov
Migrate L2TPv3 transport to the Unified Datagram Socket
Transport Backend.
Signed-off-by: Anton Ivanov
---
net/l2tpv3.c | 537 +--
1 file changed, 83 insertions(+), 454 deletions(-)
diff --git a/net/l2tpv3.c b/net
Hi Jason, hi list,
Follows a revised patchset. I have addressed most comments.
TODO: replace memcpy with dup where applicable
TODO: add force v4 option
TODO: port the UDP portion of the existing socket transport
to the new infrastructure
Future: add sendmmsg once a "bulk xmit" has been arranged
From: Anton Ivanov
Basic infrastructure to start moving datagram based transports
to a common infrastructure as well as introduce several
additional transports.
Signed-off-by: Anton Ivanov
---
configure | 12 +-
net/Makefile.objs | 2 +-
net/net.c | 4 +-
net/udst.c
On 19/07/17 15:40, Eric Blake wrote:
On 07/18/2017 12:08 PM, anton.iva...@cambridgegreys.com wrote:
From: Anton Ivanov
This adds GRETAP support to the unified socket driver.
Signed-off-by: Anton Ivanov
---
net/Makefile.objs | 2 +-
net/clients.h | 4 +
net/gre.c | 313
On 19/07/17 15:40, Eric Blake wrote:
On 07/18/2017 12:08 PM, anton.iva...@cambridgegreys.com wrote:
From: Anton Ivanov
This adds GRETAP support to the unified socket driver.
Signed-off-by: Anton Ivanov
---
net/Makefile.objs | 2 +-
net/clients.h | 4 +
net/gre.c | 313
2017年07月19日 01:08, anton.iva...@cambridgegreys.com wrote:
>> From: Anton Ivanov
>>
>> This adds raw socket support to the unified socket driver.
>
>Interesting, in fact, I've finished a tpacket backend. Let me post it
>sometime after hardfreeze.
>
>
[snip]
Could we keep l2tpv3 option?
The l2tpv3 test is actually a test for recvmmsg. If you can do one
recvmmsg transport you can do all of them.
Yes, but I wonder whether or not the check for recvmmsg is too simple.
We probably want something like what AV_VSOCK did, test the support of
e
OK. Will address both comments in next version.
Brgds,
A.
On 19/07/17 06:48, Jason Wang wrote:
On 2017年07月19日 01:08, anton.iva...@cambridgegreys.com wrote:
From: Anton Ivanov
This adds GRETAP support to the unified socket driver.
Signed-off-by: Anton Ivanov
---
net/Makefile.objs
On 19/07/17 06:39, Jason Wang wrote:
On 2017年07月19日 01:08, anton.iva...@cambridgegreys.com wrote:
From: Anton Ivanov
1. Creates a common backend for socket transports using
recvmmsg().
2. Migrates L2TPv3 to the new backend
It would be better if you could further split out 2 from this
From: Anton Ivanov
1. Creates a common backend for socket transports using
recvmmsg().
2. Migrates L2TPv3 to the new backend
Signed-off-by: Anton Ivanov
---
configure | 10 +-
net/Makefile.objs | 2 +-
net/l2tpv3.c | 531
From: Anton Ivanov
This adds raw socket support to the unified socket driver.
Signed-off-by: Anton Ivanov
---
net/Makefile.objs | 2 +-
net/clients.h | 3 ++
net/net.c | 5 +++
net/raw.c | 123 ++
qapi-schema.json
From: Anton Ivanov
This adds GRETAP support to the unified socket driver.
Signed-off-by: Anton Ivanov
---
net/Makefile.objs | 2 +-
net/clients.h | 4 +
net/gre.c | 313 ++
net/net.c | 5 +
qapi-schema.json | 46
Hi Jason, hi list,
Following is the unified socket transport patch split into parts
to make it more digestible.
Part 1 is a rewrite of the L2TPv3 driver to isolate the common
portions.
The remaining 2 patches are additional transports
In all cases the transports are switchless - they allow to
OK.
I can split it into series before next submission.
A.
On 18/07/17 08:27, Daniel P. Berrange wrote:
On Tue, Jul 18, 2017 at 07:06:27AM +0100, anton.iva...@cambridgegreys.com wrote:
From: Anton Ivanov
1. Creates a common recvmmsg backend for socket transports
2. Migrates L2TPv3 to the
Apologies, some bits of the second stage (sendmmsg) got in by mistake
and broke the patch.
I will re-submit it later today including the proposed documentation,
help and man page changes.
A.
On 18/07/17 07:12, no-re...@patchew.org wrote:
Hi,
This series failed build test on s390x host. Ple
ports in the same driver, how it should look as far as qapi, etc.
It should be possible to bring some of the existing code like half of
net/socket.c under this umbrella as well.
A.
On 18/07/17 07:06, anton.iva...@cambridgegreys.com wrote:
From: Anton Ivanov
1. Creates a common recvmmsg backen
From: Anton Ivanov
1. Creates a common recvmmsg backend for socket transports
2. Migrates L2TPv3 to the new backend
3. Adds gre socket transport - a vm can attach directly to GRE
4. Adds raw socket transport - a vm can attach directly to an
Ethernet interface
5. Adds simplistic static VXLAN
On 01/07/14 16:34, Peter Maydell wrote:
> On 1 July 2014 16:26, Anton Ivanov (antivano) wrote:
>> On 01/07/14 16:14, Peter Maydell wrote:
>>> On 1 July 2014 16:06, Anton Ivanov (antivano) wrote:
>>>> As far as general purpose linuxes, the relevant libc headers are
On 01/07/14 16:14, Peter Maydell wrote:
> On 1 July 2014 16:06, Anton Ivanov (antivano) wrote:
>> As far as general purpose linuxes, the relevant libc headers are present
>> in Ubuntul LTS 12.x and onwards, Debian 7.x, Fedora, and all other major
>> distros. I do not have
On 01/07/14 13:06, Jan Kiszka wrote:
> On 2014-06-27 16:24, Stefan Hajnoczi wrote:
>> From: Anton Ivanov
>>
>> This transport allows to connect a QEMU nic to a static Ethernet
>> over L2TPv3 tunnel. The transport supports all options present
>> in the Linux kern
On 01/07/14 15:35, Stefan Hajnoczi wrote:
> On Tue, Jul 1, 2014 at 2:58 PM, wrote:
>> From: Gonglei
>>
>> because mmsghdr struct is introduced on Linux kernel 3.3+.
>> add check for mmsghdr struct, it only gets built on hosts that
>> support mmsghdr.
Incorrect.
mmsghdr itself is Linux 2.6.32 a
On 23/06/14 12:50, Stefan Hajnoczi wrote:
> On Fri, Jun 20, 2014 at 10:34:41AM +0100, anton.iva...@kot-begemot.co.uk
> wrote:
>> From: Anton Ivanov
>>
>> This transport allows to connect a QEMU nic to a static Ethernet
>> over L2TPv3 tunnel. The transport supports
From: Anton Ivanov
This transport allows to connect a QEMU nic to a static Ethernet
over L2TPv3 tunnel. The transport supports all options present
in the Linux kernel implementation. It allows QEMU to connect
to any Linux host running kernel 3.3+, most routers and network
devices as well as
On 18/06/14 11:55, Stefan Hajnoczi wrote:
> Hi Anton,
> Still alive?
Just barely. Trying to keep my head above the snow drifts from an
avalanche of work :)
> L2TPv3 for QEMU has not been merged. Do you have an
> up-to-date series based on qemu.git/master you could send?
I will fix it to addr
From: Anton Ivanov
This transport allows to connect a QEMU nic to a static Ethernet
over L2TPv3 tunnel. The transport supports all options present
in the Linux kernel implementation. It allows QEMU to connect
to any Linux host running kernel 3.3+, most routers and network
devices as well as
On 03/04/14 13:20, Benoît Canet wrote:
> The Monday 31 Mar 2014 à 15:39:19 (+0100), anton.iva...@kot-begemot.co.uk
> wrote :
>> From: Anton Ivanov
>>
>> This transport allows to connect a QEMU nic to a static Ethernet
>> over L2TPv3 tunnel. The transport supports
if (iovcnt > MAX_L2TPV3_IOVCNT - 1) {
size_t size = iov_size(iov, iovcnt);
uint8_t *buf;
buf = g_malloc(size);
iov_to_buf(iov, iovcnt, 0, buf, size);
ret = net_l2tpv3_receive_dgram(nc, buf, size);
g_free(buf);
return ret;
}
iov_to_buf is a memcpy of the data
From: Anton Ivanov
This transport allows to connect a QEMU nic to a static Ethernet
over L2TPv3 tunnel. The transport supports all options present
in the Linux kernel implementation. It allows QEMU to connect
to any Linux host running kernel 3.3+, most routers and network
devices as well as
On 27/03/14 18:25, Stefan Hajnoczi wrote:
> On Thu, Mar 27, 2014 at 4:53 PM, Anton Ivanov (antivano)
> wrote:
>> On 27/03/14 12:30, Stefan Hajnoczi wrote:
>>> On Wed, Mar 26, 2014 at 11:08:41AM +, anton.iva...@kot-begemot.co.uk
>>> wrote:
>>>> +s
On 27/03/14 12:30, Stefan Hajnoczi wrote:
> On Wed, Mar 26, 2014 at 11:08:41AM +, anton.iva...@kot-begemot.co.uk
> wrote:
>> +static ssize_t net_l2tpv3_receive_dgram_iov(NetClientState *nc,
>> +const struct iovec *iov,
>> +int iovcnt)
>> +{
>> +NetL2
From: Anton Ivanov
This transport allows to connect a QEMU nic to a static Ethernet
over L2TPv3 tunnel. The transport supports all options present
in the Linux kernel implementation. It allows QEMU to connect
to any Linux host running kernel 3.3+, most routers and network
devices as well as
[snip]
>> So the fact that qemu_send_packet_async() has returned a non-zero does not
>> mean that we have not paid the price for it :)
> A non-zero return is simply an error code from the ->receive() function.
> In this case the packet is dropped but queuing is unaffected.
>
>> The relevant code
>> +if (!s->header_mismatch) {
>> +error_report("unknown cookie id\n");
>> +}
> Do we need to set s->header_mismatch = true to prevent flooding logs?
>
>> +return -1;
>> +}
>> +}
>> +session = (uint32_t *) (buf + s->session_offset
On 25/03/14 10:17, Stefan Hajnoczi wrote:
> On Mon, Mar 24, 2014 at 11:56:16AM +, anton.iva...@kot-begemot.co.uk
> wrote:
>> 1. Correct buffering and corect poll FSM
>>
>> Current qemu queue logic assumes single packet inputs, not multiple packet
>> RX. If the receiver cannot take more packets
From: Anton Ivanov
This transport allows to connect a QEMU nic to a static Ethernet
over L2TPv3 tunnel. The transport supports all options present
in the Linux kernel implementation. It allows QEMU to connect
to any Linux host running kernel 3.3+, most routers and network
devices as well as
On 21/03/14 15:27, Stefan Hajnoczi wrote:
> On Fri, Mar 21, 2014 at 3:06 PM, Anton Ivanov
> wrote:
>> On 21/03/14 13:14, Stefan Hajnoczi wrote:
>>> On Fri, Mar 21, 2014 at 10:01:09AM +, Anton Ivanov wrote:
>> I will probably collect all common routines and merge t
On 21/03/14 13:14, Stefan Hajnoczi wrote:
> On Fri, Mar 21, 2014 at 10:01:09AM +0000, Anton Ivanov wrote:
>> I am wondering how to re-organize these so that the code is not
>> duplicated across 3-4 drivers as well as allow people to easily add more
>> encaps in the future.
Hi list, hi all,
I am interested in what would be the best way to organize a
multiprotocol transport.
I am playing with l2tpv3 and gre - At the end of the day 90% of the
driver code for either looks the same.
If we ignore GRE checksums for a moment, the only differences are in
"form header" and
On 19/03/14 12:39, Eric Blake wrote:
> On 03/19/2014 03:31 AM, anton.iva...@kot-begemot.co.uk wrote:
>> From: Anton Ivanov
>>
>> This tranport allows to connect a qemu nic to a static Ethernet
> s/tranport/transport/
Guilty as charged :)
>
>> over L2TPv3 t
From: Anton Ivanov
This tranport allows to connect a qemu nic to a static Ethernet
over L2TPv3 tunnel. The transport supports all options present
in the linux kernel implementation. It allows qemu to connect
to any linux host running kernel 3.3+, most routers and network
devices as well as other
On 18/03/14 10:44, Stefan Hajnoczi wrote:
> On Tue, Mar 11, 2014 at 12:45:30PM +, anton.iva...@kot-begemot.co.uk
> wrote:
>> +/* This protocol number is passed getaddrinfo(), and not
>> + * used directly. If you give gettaddrinfo() what one is
>> + * supposed to give - INET, RAW, 0, the result
From: Anton Ivanov
This tranport allows to connect a qemu nic to a static Ethernet
over L2TPv3 tunnel. The transport supports all options present
in the linux kernel implementation. It allows qemu to connect
to any linux host running kernel 3.3+, most routers and network
devices as well as other
On 10/03/14 18:04, Stefan Hajnoczi wrote:
> On Mon, Mar 10, 2014 at 08:49:01AM +0000, Anton Ivanov wrote:
>> You are correct. My test is wrong.
>>
>> However, the result is the same - it wants a non-zero proto there.
>>
>> $ sudo ./gaitest
>> src ai_family 2
On 10/03/14 15:05, Stefan Hajnoczi wrote:
> On Mon, Mar 10, 2014 at 11:31:38AM +, anton.iva...@kot-begemot.co.uk
> wrote:
>> From: Anton Ivanov
>>
>> This tranport allows to connect a qemu nic to a static Ethernet
>> over L2TPv3 tunnel. The transport supports
On 10/03/14 16:06, Eric Blake wrote:
On 03/10/2014 05:31 AM, anton.iva...@kot-begemot.co.uk wrote:
From: Anton Ivanov
When sending revisions of a patch sent earlier, be sure to include
'PATCHv2' (or higher, as appropriate) in the subject,...
OK.
This tranport allows to conn
From: Anton Ivanov
This tranport allows to connect a qemu nic to a static Ethernet
over L2TPv3 tunnel. The transport supports all options present
in the linux kernel implementation. It allows qemu to connect
to any linux host running kernel 3.3+, most routers and network
Signed-off-by: Anton
You are correct. My test is wrong.
However, the result is the same - it wants a non-zero proto there.
$ sudo ./gaitest
src ai_family 2 ai_socketype 3 ai_protocol 0
socket creation failed, errno = 93
src ai_family 2 ai_socketype 3 ai_protocol 115
No error on the second one, -93 on the first one.
+ return -1;
+}
+
+freeaddrinfo(result);
+
+memset(&hints, 0, sizeof(hints));
+
+if (s->ipv6) {
+ hints.ai_family = AF_INET6;
+} else {
+ hints.ai_family = AF_INET;
+}
+if (s->udp) {
+ hints.ai_socktype = SOCK_DGRAM;
+ hints.ai_protocol
.
The idea behind using a prefix is that you can immediately determine
which area of code is affected by a commit. It also helps with grepping
the commit history although there are more precise ways to do that.
Anyway, "New feature" isn't a useful prefix.
Understood.
On 05/03/14 21:22, Eric Blake wrote:
[snip]
>
> udp is layer 3, ip is layer 2 - don't you mean "optional for tcp" as the
> layer 3 counterpart of udp?
L2TPv3 uses either udp or ip as in "raw ip" (raw sockets) using a
special protocol - 0x73.
So no tcp at play here. The wording is incorrect - sho
From: Anton Ivanov
This transport allows qemu to communicate with host if host
supports L2TPv3, communicate directly VM to VM (similar to
current socket transport) and VM to other device - f.e. VM to
a router.
Supported
* Raw IPv4, Raw IPv6, UDPv4 and UDPv6 as per RFC
* No cookie, 32
ire transport.
>> [snip]
>>
>> Please see http://wiki.qemu.org/Contribute/SubmitAPatch - in particular
>> the patch should be sent as inline text rather than as attachment (so
>> that we can comment inline on it), also it is missing a Signed-off-by
>> (without it patches cannot get accepted) and
Hi all,
This is a functional driver which will interoperate versus most L2TPv3
implementations. It cannot be split into smaller patches - this is an
entire transport.
It will get one small incremental update at a later date. Some broken
l2tpv3 implementations require a counter field but do not
On 04/03/14 15:53, Eric Blake wrote:
> On 03/04/2014 08:22 AM, Anton Ivanov (antivano) wrote:
>> Apologies, missed to diff the json definitions.
>>
>> Attached.
>>
> Missing a commit message and a Signed-off-by line, so it can't be
> applied as-is. Also, we
On 04/03/14 16:55, Paolo Bonzini wrote:
> Il 04/03/2014 17:48, Anton Ivanov (antivano) ha scritto:
>>>> >> +static ssize_t net_l2tpv3_receive_dgram_iov(NetClientState *nc,
>>>> const struct iovec *iov, int iovcnt)
>>> > Long line; you can
On 04/03/14 16:33, Eric Blake wrote:
>
> +
> +
> +#define PAGE_SIZE 4096
> One of your earlier review comments suggested using sysconf or else
> renaming this, as not all systems have a page size of 4096.
OK.
>
>> +#define IOVSIZE 2
>> +#define MAX_L2TPV3_MSGCNT 32
>> +#define MAX_L2TPV3_IOVCNT (
On 04/03/14 15:53, Eric Blake wrote:
> On 03/04/2014 08:22 AM, Anton Ivanov (antivano) wrote:
>> Apologies, missed to diff the json definitions.
>>
>> Attached.
>>
> Missing a commit message and a Signed-off-by line, so it can't be
> applied as-is. Also, we
On 04/03/14 15:41, Eric Blake wrote:
> On 03/04/2014 08:19 AM, Anton Ivanov (antivano) wrote:
>> Attached is a revised version.
> Better is to post a new top-level thread, with [PATCHv2] in the title.
> Also, one of the v1 review comments was to break this into smaller
> self
Apologies, missed to diff the json definitions.
Attached.
On 04/03/14 15:19, Anton Ivanov wrote:
> Attached is a revised version.
>
> * I am still keeping the sendmsg instead of iov_send because I
> have not had the time to review udp.c in the kernel and do the
> rele
Attached is a revised version.
* I am still keeping the sendmsg instead of iov_send because I have
not had the time to review udp.c in the kernel and do the relevant
regression testing to see if they connect() still breaks bind() on
multihomed hosts as it did in 2.6. We can revisit that at
Hi Stefan,
I am addressing a few more comments which I missed on first pass.
> If you really *need* the page size, please use sysconf(_SC_PAGESIZE).
I like to have it page aligned and if possible page sized so I can later
extend to do jumbo frame support via a vector. If this is the wrong way
On 04/03/14 09:36, Stefan Hajnoczi wrote:
> On Mon, Mar 03, 2014 at 02:01:00PM +0000, Anton Ivanov (antivano) wrote:
>> On 03/03/14 13:27, Stefan Hajnoczi wrote:
>>> On Fri, Feb 28, 2014 at 08:28:11AM +, Anton Ivanov (antivano) wrote:
>>>> 3. Qemu to communicate w
On 03/03/14 13:27, Stefan Hajnoczi wrote:
> On Fri, Feb 28, 2014 at 08:28:11AM +0000, Anton Ivanov (antivano) wrote:
>> 3. Qemu to communicate with the local host, remote vms, network devices,
>> etc at speeds which for a number of use cases exceed the speed of the
>> lega
[snip]
>>> s/1.0/2.0/
>> OK - just to clarify, which version is this referring to - qemu, api, etc?
> This field is the version of qemu that first contains the release. If
> your patch is on time to make the qemu 2.0 release, then 2.0 is
> appropriate; but we're close to feature freeze so it may
I now remember why I am not using connected sockets.
connect() in UDP used to break source address bind(). I had a bug filed
vs that as far back as early 2.6 which everyone ignored for ages. It was
showing as bug vs hpa-tftpd.
I need to reverify if this is still the case as it has to keep a
parti
On 28/02/14 13:40, Eric Blake wrote:
> On 02/28/2014 01:28 AM, Anton Ivanov (antivano) wrote:
>> Hi all,
>>
>> On behalf of Cisco Systems I am authorized to contribute a new transport
>> to the network subsystem in qemu.
>>
>> Patch attached.
> Your patc
On 28/02/14 11:36, Paolo Bonzini wrote:
> Il 28/02/2014 12:17, Anton Ivanov (antivano) ha scritto:
>>> > As mentioned below, I suggest storing the cookies and session ids in
>>> > host order in NetL2TPV3State, and doing the conversion in
>>> > l2tpv3_form
On 28/02/14 10:02, Paolo Bonzini wrote:
>> This transport uses a linux specific call to get several GBit RX rate.
>
> Might as well mention that it's recvmmsg. :)
:)
>
>> This call can be wrapped (at some cost) in a compatibility loop using
>> posix compliant recvmsg instead for other systems. As
Hi all,
On behalf of Cisco Systems I am authorized to contribute a new transport
to the network subsystem in qemu.
Specifically, we would like to contribute a new transport:
L2TPv3 static tunnel network transport.
Earlier versions of this (we have patchsets going back to qemu-1.0) have
been use
86 matches
Mail list logo
