From owner-freebsd-net@FreeBSD.ORG Thu Dec 20 18:06:08 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E4C1843A for ; Thu, 20 Dec 2012 18:06:08 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ea0-f176.google.com (mail-ea0-f176.google.com [209.85.215.176]) by mx1.freebsd.org (Postfix) with ESMTP id 6D3828FC0C for ; Thu, 20 Dec 2012 18:06:07 +0000 (UTC) Received: by mail-ea0-f176.google.com with SMTP id d13so1533142eaa.21 for ; Thu, 20 Dec 2012 10:06:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UwkYrxZBRpj4vYccpWXAGJ5lBDsmknB5ZWJakskfgiw=; b=d4550uN2j3jsZjCZ/Z4TnlG67lvMG6mg9owkBpc19iCScIXu7olOOVsHUU1kCV0Mki wi/VqPfq1rHvZVkrpgb/kGA8sf1w9dWMppOMNoOwrelXVNh8VE/Hy7N00NYUlNxhxz3C IurrcQcTgR3ODAjM56dqXZg15ozPLqaHQn7ZBZHy95VHotPhNT/OfIFpakPyQPndvs+f 7OhPMu++EngmlY/Qsq6pA1ciyjcz9UY4khy031XQA8U4udQExQYv/iVqmHqlsIwdpLeo r4JkegDvXqBYaeSfDMT6PnGTOVSERUxG9tzLhO/YayZH/Rf83ZHMEeCh6cOAo2lgV3Yg c0Rw== MIME-Version: 1.0 Received: by 10.14.216.70 with SMTP id f46mr25000238eep.12.1356026767289; Thu, 20 Dec 2012 10:06:07 -0800 (PST) Received: by 10.223.101.77 with HTTP; Thu, 20 Dec 2012 10:06:07 -0800 (PST) In-Reply-To: <50D338DB.5070907@gmail.com> References: <50D218BA.7080301@FreeBSD.org> <50D21C3B.8020803@gmail.com> <50D24774.80800@gmail.com> <50D338DB.5070907@gmail.com> Date: Thu, 20 Dec 2012 10:06:07 -0800 Message-ID: Subject: Re: use of V_tcbinfo lock for TCP syncache From: Vijay Singh To: Karim Fodil-Lemelin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Navdeep Parhar X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 18:06:09 -0000 > How do you plan to handle the fact that most of tcp_input() and > tcp_do_segment() require at least a read lock held on the pcbinfo lock? Yes, I realized that after some experiments yesterday. > Is your goal to reduce the amount of code that gets executed under the write > lock protection of pcbinfo or completely get rid of the lock all together? While these are good goals, mine is simply to avoid making the socket upcall with the pcbinfo lock held, due to peculiarities in my environment.