All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amos Kong <akong@redhat.com>
To: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: aliguori@us.ibm.com, kvm@vger.kernel.org, quintela@redhat.com,
	jasowang@redhat.com, qemu-devel@nongnu.org, owasserm@redhat.com,
	laine@redhat.com
Subject: Re: [PATCH v3 1/9] net: introduce tcp_server_start()
Date: Fri, 16 Mar 2012 18:47:55 +0800	[thread overview]
Message-ID: <4F631A5B.6050206@redhat.com> (raw)
In-Reply-To: <20120314145836.GA2894@illuin>

On 14/03/12 22:58, Michael Roth wrote:
> On Wed, Mar 14, 2012 at 04:33:14PM +0800, Amos Kong wrote:
>> On 14/03/12 00:39, Michael Roth wrote:
>>> On Wed, Mar 07, 2012 at 06:47:45AM +0800, Amos Kong wrote:
>>>> Introduce tcp_server_start() by moving original code in
>>>> tcp_start_incoming_migration().
>>>>
>>>> Signed-off-by: Amos Kong<akong@redhat.com>
>>>> ---
>>>>   net.c         |   28 ++++++++++++++++++++++++++++
>>>>   qemu_socket.h |    2 ++
>>>>   2 files changed, 30 insertions(+), 0 deletions(-)
>>>>
>>>> +int tcp_server_start(const char *str, int *fd)
>>>> +{

>>> I would combine this with patch 2, since it provides context for why
>>> this function is being added. Would also do the same for 3 and 4.
>>>
>>> I see client the client implementation you need to pass fd back by
>>> reference since ret can be set to EINPROGRESS/EWOULDBLOCK on success,
>>
>> ret restores 0 or -socket_error()
>>   success: 0, -EINPROGRESS
>>   fail   : ret<  0&&  ret !=-EINTR&&  ret != -EWOULDBLOCK
>>
>> , it should be -EINPROGRESS
>
> I see, I think I was confued by patch #4 where you do a
>
> +    ret = tcp_client_start(host_port,&s->fd);
> +    if (ret == -EINPROGRESS || ret == -EWOULDBLOCK) {
> +        DPRINTF("connect in progress");
> +        qemu_set_fd_handler2(s->fd, NULL, NULL, tcp_wait_for_connect, s);
>
> If ret == EWOULDBLOCK is a failure (or if the call isn't supposed to
> return EWOULDBLOCK), we should fail it there rather than passing it on to
> tcp_wait_for_connect().

You are right, it should be :
        if (ret == -EINPROGRESS) {

>>> Also, is there any reason we can't re-use
>>> qemu-sockets.c:inet_listen()/qemu-sockets.c:inet_connect()? AFAICT they
>>> serve the same purpose, and already include some of the work from your
>>> PATCH #6.
>>
>> We could not directly use it, there are some difference,
>> such as tcp_start_incoming_migration() doesn't set socket no-blocked,
>> but net_socket_listen_init() sets socket no-blocked.
>
> I think adding a common function with blocking/non-blocking flag and
> having inet_listen_opts()/socket_listen_opts() call it with a wrapper
> would be reasonable.

> A lot of code is being introduced here to solve problems that are
> already handled in qemu-sockets.c. inet_listen()/inet_connect()
> already handles backeted-enclosed ipv6 addrs, getting port numbers when
> there's more than one colon, getaddrinfo()-based connections, and most
> importantly it's had ipv6 support from day 1.

> Not 100% sure it'll work for what you're doing, but qemu-sockets.c was
> specifically added for this type of use-case and is heavilly used
> currently (vnc, nbd, Chardev users), so I think we should use it unless
> there's a good reason not to.

There are many special request for migration, which is not implemented in
inet_listen_opts()/socket_listen_opts(), but many codes can be reused,
I would re-write patches.

Thanks, Amos

WARNING: multiple messages have this Message-ID (diff)
From: Amos Kong <akong@redhat.com>
To: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: aliguori@us.ibm.com, kvm@vger.kernel.org, quintela@redhat.com,
	jasowang@redhat.com, qemu-devel@nongnu.org, owasserm@redhat.com,
	laine@redhat.com
Subject: Re: [Qemu-devel] [PATCH v3 1/9] net: introduce tcp_server_start()
Date: Fri, 16 Mar 2012 18:47:55 +0800	[thread overview]
Message-ID: <4F631A5B.6050206@redhat.com> (raw)
In-Reply-To: <20120314145836.GA2894@illuin>

On 14/03/12 22:58, Michael Roth wrote:
> On Wed, Mar 14, 2012 at 04:33:14PM +0800, Amos Kong wrote:
>> On 14/03/12 00:39, Michael Roth wrote:
>>> On Wed, Mar 07, 2012 at 06:47:45AM +0800, Amos Kong wrote:
>>>> Introduce tcp_server_start() by moving original code in
>>>> tcp_start_incoming_migration().
>>>>
>>>> Signed-off-by: Amos Kong<akong@redhat.com>
>>>> ---
>>>>   net.c         |   28 ++++++++++++++++++++++++++++
>>>>   qemu_socket.h |    2 ++
>>>>   2 files changed, 30 insertions(+), 0 deletions(-)
>>>>
>>>> +int tcp_server_start(const char *str, int *fd)
>>>> +{

>>> I would combine this with patch 2, since it provides context for why
>>> this function is being added. Would also do the same for 3 and 4.
>>>
>>> I see client the client implementation you need to pass fd back by
>>> reference since ret can be set to EINPROGRESS/EWOULDBLOCK on success,
>>
>> ret restores 0 or -socket_error()
>>   success: 0, -EINPROGRESS
>>   fail   : ret<  0&&  ret !=-EINTR&&  ret != -EWOULDBLOCK
>>
>> , it should be -EINPROGRESS
>
> I see, I think I was confued by patch #4 where you do a
>
> +    ret = tcp_client_start(host_port,&s->fd);
> +    if (ret == -EINPROGRESS || ret == -EWOULDBLOCK) {
> +        DPRINTF("connect in progress");
> +        qemu_set_fd_handler2(s->fd, NULL, NULL, tcp_wait_for_connect, s);
>
> If ret == EWOULDBLOCK is a failure (or if the call isn't supposed to
> return EWOULDBLOCK), we should fail it there rather than passing it on to
> tcp_wait_for_connect().

You are right, it should be :
        if (ret == -EINPROGRESS) {

>>> Also, is there any reason we can't re-use
>>> qemu-sockets.c:inet_listen()/qemu-sockets.c:inet_connect()? AFAICT they
>>> serve the same purpose, and already include some of the work from your
>>> PATCH #6.
>>
>> We could not directly use it, there are some difference,
>> such as tcp_start_incoming_migration() doesn't set socket no-blocked,
>> but net_socket_listen_init() sets socket no-blocked.
>
> I think adding a common function with blocking/non-blocking flag and
> having inet_listen_opts()/socket_listen_opts() call it with a wrapper
> would be reasonable.

> A lot of code is being introduced here to solve problems that are
> already handled in qemu-sockets.c. inet_listen()/inet_connect()
> already handles backeted-enclosed ipv6 addrs, getting port numbers when
> there's more than one colon, getaddrinfo()-based connections, and most
> importantly it's had ipv6 support from day 1.

> Not 100% sure it'll work for what you're doing, but qemu-sockets.c was
> specifically added for this type of use-case and is heavilly used
> currently (vnc, nbd, Chardev users), so I think we should use it unless
> there's a good reason not to.

There are many special request for migration, which is not implemented in
inet_listen_opts()/socket_listen_opts(), but many codes can be reused,
I would re-write patches.

Thanks, Amos

  reply	other threads:[~2012-03-16 10:47 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-06 22:47 [PATCH v3 0/9] support to migrate with IPv6 address Amos Kong
2012-03-06 22:47 ` [Qemu-devel] " Amos Kong
2012-03-06 22:47 ` [PATCH v3 1/9] net: introduce tcp_server_start() Amos Kong
2012-03-06 22:47   ` [Qemu-devel] " Amos Kong
2012-03-13 16:39   ` Michael Roth
2012-03-14  8:33     ` Amos Kong
2012-03-14 14:58       ` Michael Roth
2012-03-16 10:47         ` Amos Kong [this message]
2012-03-16 10:47           ` Amos Kong
2012-03-14  7:14   ` Orit Wasserman
2012-03-14  7:27     ` Paolo Bonzini
2012-03-14  7:27       ` Paolo Bonzini
2012-03-14  7:51       ` Amos Kong
2012-03-14  7:51         ` Amos Kong
2012-03-14  8:28         ` Paolo Bonzini
2012-03-14  8:28           ` Paolo Bonzini
2012-03-14 10:03         ` Orit Wasserman
2012-03-14 10:03           ` Orit Wasserman
2012-03-14 11:39         ` Kevin Wolf
2012-03-14 11:39           ` Kevin Wolf
2012-03-06 22:47 ` [PATCH v3 2/9] net: use tcp_server_start() for tcp server creation Amos Kong
2012-03-06 22:47   ` [Qemu-devel] " Amos Kong
2012-03-06 22:48 ` [PATCH v3 3/9] net: introduce tcp_client_start() Amos Kong
2012-03-06 22:48   ` [Qemu-devel] " Amos Kong
2012-03-13 18:35   ` Michael Roth
2012-03-14 10:19     ` Amos Kong
2012-03-14 15:30       ` Michael Roth
2012-03-14  7:31   ` Orit Wasserman
2012-03-06 22:48 ` [PATCH v3 4/9] net: use tcp_client_start for tcp client creation Amos Kong
2012-03-06 22:48   ` [Qemu-devel] " Amos Kong
2012-03-06 22:48 ` [PATCH v3 5/9] net: refector tcp_*_start functions Amos Kong
2012-03-06 22:48   ` [Qemu-devel] " Amos Kong
2012-03-06 22:48 ` [PATCH v3 6/9] net: use getaddrinfo() in tcp_start_common Amos Kong
2012-03-06 22:48   ` [Qemu-devel] " Amos Kong
2012-03-06 22:48 ` [PATCH v3 7/9] net: introduce parse_host_port_info() Amos Kong
2012-03-06 22:48   ` [Qemu-devel] " Amos Kong
2012-03-06 22:48 ` [PATCH v3 8/9] net: split hostname and service by last colon Amos Kong
2012-03-06 22:48   ` [Qemu-devel] " Amos Kong
2012-03-13 19:34   ` Michael Roth
2012-03-06 22:48 ` [PATCH v3 9/9] net: support to include ipv6 address by brackets Amos Kong
2012-03-06 22:48   ` [Qemu-devel] " Amos Kong
2012-03-13 19:47   ` Michael Roth
2012-03-14  9:58     ` Amos Kong
2012-03-14  9:58       ` [Qemu-devel] " Amos Kong
2012-03-14 15:38       ` Michael Roth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F631A5B.6050206@redhat.com \
    --to=akong@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=jasowang@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=laine@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=owasserm@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.