From owner-freebsd-current@FreeBSD.ORG Tue Aug 26 09:48:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A351906 for ; Tue, 26 Aug 2014 09:48:32 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E4798310F for ; Tue, 26 Aug 2014 09:48:31 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id m15so14023840wgh.3 for ; Tue, 26 Aug 2014 02:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=79209HSGt7D0aj2xfpLLd8qq8MABVEoLhTTPONH1KHU=; b=UWIn8OxFDpJDuIbLoOyHP4p0eKkg42YCNfIfE9jdhqfmDr+3KT+/9vG1sGRaGQMQb9 NsAhTfWtSoKRVeV6cmodx33r4plSNVFD7nfpt6NxKWdw8E8bCzG1OB84hjP7vpBTwVEM 6fy3UEU3sqXc2KRw+K79ZZu9RgAfJ/u0fNX4S2k8o2zxt0/eYfOQkxmOoLhf0u4KaJ4D vuSMEIM+brykUzQdEx/uyaSDoag5XBTvIa1LJl+gORSKFY32hr/4KQZ5otQ9Nj/qU2oS JQoHbZW7TdQqphshBYZUrwRCF31G4WeNYaW4cR4IMXUEm3u7+0jnBTtJB6J8S00VHN1g g+jg== X-Received: by 10.195.12.4 with SMTP id em4mr8792785wjd.98.1409046510176; Tue, 26 Aug 2014 02:48:30 -0700 (PDT) Received: from [192.168.178.121] (p5B36D7F5.dip0.t-ipconnect.de. [91.54.215.245]) by mx.google.com with ESMTPSA id l3sm10364916wib.11.2014.08.26.02.48.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Aug 2014 02:48:29 -0700 (PDT) Message-ID: <53FC57EC.2000107@gmail.com> Date: Tue, 26 Aug 2014 11:48:28 +0200 From: =?windows-1252?Q?Jan_Kokem=FCller?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Fedor Indutny , freebsd-current@freebsd.org Subject: Re: KQueue 0-length UDP packet References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 09:48:32 -0000 Hi, > What I wanted to ask is: why does FreeBSD kqueue implementation treat > `SO_RCVLOWAT` as a raw packet size watermark, and not using the actual > data size for filtering out events? It looks like SO_RCVLOWAT refers to the number of bytes in the socket buffer, not raw packet bytes. In the case of an arriving UDP packet there is always a 'struct sockaddr' in the buffer that contains the source address/port of the message. For IPv4 this is 16 bytes and for IPv6 28 bytes. I think this is intended behavior, as this is data you can "read" with recvfrom or recvmsg. POSIX says "Receive calls may still return less than the low water mark if an error occurs, a signal is caught, or the type of data next in the receive queue is different from that returned (for example, out-of-band data)." So in this case this data is address data. On the other hand, NOTE_LOWAT from kevent refers to data/protocol bytes. The semantics were changed in 2002: http://marc.info/?l=freebsd-arch&m=103587526507822&w=2 The value you get in 'data' also refers to the number of protocol data bytes available. I've had a look at how OpenBSD handles this. It returns the number of protocol data bytes with "ioctl(s, FIONREAD, &len)" but the number of bytes in the socket buffer in the 'data' member of kevent, so exactly the other way around compared to FreeBSD. SO_RCVLOWAT works still the same, though. Cheers, Jan