qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Unified Datagram Socket Transport


From: Anton Ivanov
Subject: Re: [Qemu-devel] Unified Datagram Socket Transport
Date: Fri, 21 Jul 2017 05:25:37 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0



On 21/07/17 04:55, Jason Wang wrote:


On 2017年07月21日 03:12, address@hidden 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 (raw
sockets - GRE, L2TPv3, etc).

It also includes a port of the original socket.c transport to
the new UDST backend. The relevant code is ifdef-ed so there
should be no effect on other systems.

This looks sub-optimal. If you want to do this, I would rather suggest you just extend the socket dgram backend like what udst did now.

Apologies, do you mean extend it further to handle the tcp form?

That does not work at present. Sure, you can receive tcp using recvmmsg, but you cannot use it to handle a tcp based variable length encaps where frame lengths are set in a header. That can be done only be sequential read() or recv() to read the frame length first, then the frame.

I can in theory add that to a unified socket backend, but this is completely different tx and rx logic - so it will become suboptimal (and quite ugly). It will need different tx and rx functions and appropriate initialization to select them. I'd rather keep it to datagram only - what says on the tin.



I think that this is would be the appropriate place to stop in this
iteration. I would prefer to have this polished, before I start
looking at sendmmsg and bulk send or some of the more unpleasant
encapsulations like geneve.

Pay attention we're softfreeze now. So the feature is for 2.11, if it looks good, I can only queue it for 2.11.

OK. Understood.


Btw, looks like not all comments of v1 were addressed.

I will go through the comments one more time. I realized I may have missed converting malloc to a g_memdup in a couple places.


Thanks

Best Regards,

A.



A.





--
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]