From owner-freebsd-net@FreeBSD.ORG Wed Apr 25 15:45:12 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADEB11065678; Wed, 25 Apr 2012 15:45:12 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 334A18FC15; Wed, 25 Apr 2012 15:45:12 +0000 (UTC) Received: by yhgm50 with SMTP id m50so282009yhg.13 for ; Wed, 25 Apr 2012 08:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=vlR8m2g4tqqSz11sCsSsUkgtpcLTaR1ytOav32j6jpU=; b=U/Xu3awCKqpc0VWcVq0gyrDAOF0COtnqtc29mwN83N5w/p3t33/hOOKFOM6wf+muxu 2a5/Wr2PNcRvnz30fGGXfnPIFB+fXw8AJB7OHqk/YdI/FccQYPOsYEjCdkaz5+0716lq UR1h8Q9rS8zorSJwtwlHStk1GL3AU/zI+JSh1IABIRKDN+uGCKXQkUpnmneZBhXEleXX UM7eMMDdWxnVk+uKdCKKEeCkUbM9YQaEI5zHeGypJ7N6G7N5cOsqC1/FlHjN+wYroo9k /8Cn4SLtrv4dRNtcVq6JPFEZr+x5DfO7UrwiXoFk6CIAFmvy2K20mb+3GuRJDO5AIcMO Iymg== MIME-Version: 1.0 Received: by 10.50.51.197 with SMTP id m5mr3196478igo.38.1335368711190; Wed, 25 Apr 2012 08:45:11 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.50.129.39 with HTTP; Wed, 25 Apr 2012 08:45:11 -0700 (PDT) In-Reply-To: <7FC5708C-429D-4077-9A3C-6272AB1316D9@FreeBSD.org> References: <20120419133018.GA91364@onelab2.iet.unipi.it> <4F907011.9080602@freebsd.org> <20120419204622.GA94904@onelab2.iet.unipi.it> <20120424163423.GA59530@onelab2.iet.unipi.it> <5C2FC09E-1873-4A97-8980-07B336D3DC44@netasq.com> <7FC5708C-429D-4077-9A3C-6272AB1316D9@FreeBSD.org> Date: Wed, 25 Apr 2012 17:45:11 +0200 X-Google-Sender-Auth: fwlNrlBMvWtLhOyHzd2aIp2Yc7w Message-ID: From: "K. Macy" To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Cc: "Li, Qing" , Fabien Thomas , current@freebsd.org, net@freebsd.org Subject: Re: Some performance measurements on the FreeBSD network stack 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: Wed, 25 Apr 2012 15:45:12 -0000 > Because there were leaks, there were 100% panics for IPv6, ... at least on > the version I had seen in autumn last year. > > There is certainly no one more interested then me on these in, esp. for v6 > where the removal of route caching a long time ago made nd6_nud_hint() a NOP > with dst and rt being passed down as NULL only, and where we are doing up to > three route lookups in the output path if no cached rt is passed down along > from the ULP. > > If there is an updated patch, I'd love to see it. Ok, I'm following up as this seems to be getting some interest. This the relevant part of the last mail that I received from you. The final part having been dedicated to the narrow potential ABI changes that were to make it in to the release. From: Bjoern A. Zeeb Date: Mon, Sep 19, 2011 at 3:19 PM To: "K. Macy" Cc: Robert Watson , rysto32 , Qing Li Sorry it's taking me so long while I was travelling but also now being back home again. I would yet have to find a code path through IPv6 that will a) not panic on INVARIANTS and b) actually update the inp_lle cache. Once I stop finding the next hiccup going one step deeper into the stack (and I made it to if_ethersubr.c) I'll get to legacy IP and the beef and I'll hope that all you all will have reviewed and tested that thoroughly. Checking whether a similar problem would exist in v4 I however found a possible lle reference leak in the legacy IP path as well. There's also a missed place where we do not update the generation counter (even though kind of pointless place but still to do for completeness). I am also pondering why we are not always invalidating the ro_lle cache (when we update the ro_rt entry in the callgraph after tcp_output). I wonder if we can provoke strange results say changing the default route from something connected on interface 1 to interface 2. <...> /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. =================================================================== The only comment in here which was sufficiently specific to actually take action on was: "pondering why we are not always invalidating the ro_lle cache (when we update the ro_rt entry in the callgraph after tcp_output)." Which was subsequently addressed by ensuring that the LLE_VALID flag was actually meaningful by clearing it when the llentry is removed from the interface's hash table in an unrelated commit because of weird behaviour observed with the flow. a) Where is the possible leak in the legacy path? b) Where were the panics in v6? In light of the fact that I don't or at least didn't have any means of testing v6 (I can probably get a testbed set up at iX now) and the netinet6 specific portions of the patch consist of 4 lines of code which should really be entrusted to you given that your performance parity work for v6 has actively being funded, it was clearly a mistake to tie the fate of the patch as a whole to those narrow bits. Once I get a response to a) and b) I'll follow up with a patch against head. I'm sure whatever I had has bitrotted somewhat in the meantime. Thanks for your help, Kip