From owner-freebsd-net@FreeBSD.ORG Mon Oct 25 06:40:14 2010 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 617B11065673; Mon, 25 Oct 2010 06:40:14 +0000 (UTC) (envelope-from gsriram@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 26BEA8FC15; Mon, 25 Oct 2010 06:40:13 +0000 (UTC) Received: by pvc22 with SMTP id 22so412180pvc.13 for ; Sun, 24 Oct 2010 23:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=+i0dxNVoYEwsIUqTTJakfLKu9nvmZOgHWxdNd2S2VMA=; b=QE90uAS7zI6zU4LXijMzogFytkDkTheG34ZB+kUIcdGeJn/g+ClqfJ2PnJ5tJK2Tnt 6IxQ5K1zNULSCdh6KzW0qvln7jXUr/RNTqlmEjuI0j5v4caSgB3QbL9mwYBfuXTs57kU Y0V5suUbhUbyh4E+9oSqyR2Gs6zOyrbMXEG7U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kpGjDgEN6ISJiY9PPHa2upzTAEN3zVg6VkzSu1/vMaiX23rW8OvzS76m4qaksDkD4P P71R0TbFMmsydKhnchnT2b0Jdh0hj8qTvRsycw5O/ibQBJD4uXMFLzBEOduDZoR6Dp9l lz4dKQV33q1amp5/G5kYh7i2SiT3cpY+TQHOw= MIME-Version: 1.0 Received: by 10.142.136.12 with SMTP id j12mr5107117wfd.148.1287988813617; Sun, 24 Oct 2010 23:40:13 -0700 (PDT) Received: by 10.143.156.8 with HTTP; Sun, 24 Oct 2010 23:40:13 -0700 (PDT) In-Reply-To: <4CC2254C.7070104@freebsd.org> References: <4CA5D1F0.3000307@freebsd.org> <4CA9B6AC.20403@freebsd.org> <4CBB6CE9.1030009@freebsd.org> <4CC2254C.7070104@freebsd.org> Date: Mon, 25 Oct 2010 12:10:13 +0530 Message-ID: From: Sriram Gorti To: Lawrence Stewart Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Andre Oppermann Subject: Re: Question on TCP reassembly counter 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: Mon, 25 Oct 2010 06:40:14 -0000 Hi, On Sat, Oct 23, 2010 at 5:29 AM, Lawrence Stewart wrote: > On 10/22/10 18:10, Sriram Gorti wrote: >> Hi, >> >> On Mon, Oct 18, 2010 at 3:08 AM, Lawrence Stewart wrote: >> >> Thanks for the fix. Tried it on XLR/XLS and the earlier tests pass >> now. net.inet.tcp.reass.overflows was always zero after the tests (and >> in the samples I took while the tests were running). > > Great, thanks for testing. > >> One observation though: net.inet.tcp.reass.cursegments was non-zero >> (it was just 1) after 30 rounds, where each round is (as earlier) >> 15-concurrent instances of netperf for 20s. This was on the netserver >> side. And, it was zero before the netperf runs. On the other hand, >> Andre told me (in a separate mail) that this counter is not relevant >> anymore - so, should I just ignore it ? > > It's relevant, just not guaranteed to be 100% accurate at any given > point in time. The value is calculated based on synchronised access to > UMA zone stats and unsynchronised access to UMA per-cpu zone stats. The > latter is safe, but causes the overall result to potentially be > inaccurate due to use of stale data. The accuracy vs overhead tradeoff > was deemed worthwhile for informational counters like this one. > > That being said, I would not expect the value to remain persistently at > 1 after all TCP activity has finished on the machine. It won't affect > performance, but I'm curious to know if the calculation method has a > flaw. I'll try to reproduce locally, but can you please confirm if the > value stays at 1 even after many minutes of no TCP activity? > This behavior does repeat easily but finally it did. Even after leaving the system alone (other than for background NFS messages) for a few mins, the value persists. After a little more investigation, it is observed that one of the spawned netserver's has not terminated and when it is explicitly terminated, the sysctl of interest drops back to zero. Does that mean the TCP reassembly portion is doing okay ? But, it opens up the question of why the netserver has not terminated. I will dig further into it but if you have any quick suggestions, they are most welcome. thanks, Sriram