From owner-freebsd-net@FreeBSD.ORG Sun Jun 19 21:26:46 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40F49106566C; Sun, 19 Jun 2011 21:26:46 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9452D8FC15; Sun, 19 Jun 2011 21:26:45 +0000 (UTC) Received: by fxm11 with SMTP id 11so1649846fxm.13 for ; Sun, 19 Jun 2011 14:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:references:x-comment-to :sender:date:in-reply-to:message-id:user-agent:mime-version :content-type; bh=Cg3KOH3QRUT9rvk4RgWBoCYpxkDW/83BU42cU6Ix6EA=; b=J6DtL2TMaKGR3jNUSfwi7AU5ETORLAPlPq2dO3QNu7bxx9tntl9s5gehUEB/IoVwBP aQJe5YU0yQXWSa8r+A3zChsz6v46xHqh/tNYbHk4TrUaXkXn060hGHxh5hDKbqVfypiA wwK7zshWBJYY+Ao5BM3KOCNODx4zG++Lb4rzg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=WiCX/g8VwqNbBe+fRSSuf9m3P79N0S39iOhDQntXnI97+XHS2kcX5GbyYRKWDWAMWC wmdxVh9ngODB2D6TsBPim45DAuPJSEZmrdcTpkepFCsWgkWcOqYGwiD1Fp5a0Ymp4jxl t4o+phIT7mk+3+0LBGUSMh+PdCvlhLAw9eKTE= Received: by 10.223.64.66 with SMTP id d2mr3869365fai.116.1308518804346; Sun, 19 Jun 2011 14:26:44 -0700 (PDT) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id h1sm2448148fag.11.2011.06.19.14.26.41 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 19 Jun 2011 14:26:42 -0700 (PDT) From: Mikolaj Golub To: Kostik Belousov References: <86pqmhn1pf.fsf@kopusha.home.net> <20110614092303.GG48734@deviant.kiev.zoral.com.ua> <86k4cntwz2.fsf@in138.ua3> <20110619094403.GD48734@deviant.kiev.zoral.com.ua> X-Comment-To: Kostik Belousov Sender: Mikolaj Golub Date: Mon, 20 Jun 2011 00:26:39 +0300 In-Reply-To: <20110619094403.GD48734@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Sun, 19 Jun 2011 12:44:03 +0300") Message-ID: <86r56p7bsg.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org, Pawel Jakub Dawidek Subject: Re: Scenario to make recv(MSG_WAITALL) stuck X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 21:26:46 -0000 On Sun, 19 Jun 2011 12:44:03 +0300 Kostik Belousov wrote: KB> On Wed, Jun 15, 2011 at 09:44:33AM +0300, Mikolaj Golub wrote: >> >> On Tue, 14 Jun 2011 12:23:03 +0300 Kostik Belousov wrote: >> >> KB> I do not understand what then happens for the recvfrom(2) call ? >> KB> Would it get some error, or 0 as return and no data, or something else ? >> >> It will wait for data below in another loop ("Now continue to read any data >> mbufs off of the head..."). >> >> Elaborating, I would split soreceive_generic on three logical parts. >> >> In the first (restart) part we block until some data are received and also >> (without the patch) in the case of MSG_WAITALL if the buffer is big enough we >> block until all MSG_WAITALL request is received (actually it will spin in >> "goto restart" loop until some condition becomes invalid). >> >> The second part is some processing of received data and the third part is a >> "while" loop where data is copied to userspace and in the case of MSG_WAITALL >> request if not all data is received to satisfy the request it also waits for >> this data. >> >> My patch removes the condition in the first part in the case of MSG_WAITALL to >> wait for all data if buffer is big enough. We always will wait for the rest of >> data in the third part. It might be not so effective, and this is my first >> concern about the patch (although not big :-). KB> Now I think that this part of the patch is right. KB> The loop in the soreceive_generic() would behave as I would expect KB> it for MSG_WAITALL. It copyout the received data to userspace by KB> received chunks. KB> I do not understand your note about effectiveness there. The old behaviour: if only a part of the request is recived and the buffer is large enough, wait for the rest and then go to processing. The new behaviour: if a part of data is recived, (unconditionally) process it and wait for the rest (and process). The first one looks a little more efficient (but has the issue for edge case with nearly full buffer). -- Mikolaj Golub