From owner-freebsd-transport@freebsd.org Wed Jul 20 19:09:36 2016 Return-Path: Delivered-To: freebsd-transport@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B9D7B9F7F7 for ; Wed, 20 Jul 2016 19:09:36 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 152751729 for ; Wed, 20 Jul 2016 19:09:36 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-it0-x236.google.com with SMTP id f6so58662728ith.0 for ; Wed, 20 Jul 2016 12:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xYNeUbasf66NuWbP1g4BVnra6eiuMLOJKZxS1yFyPJc=; b=An+9+fVsTHJqDNR35yhJoZ+9aWk1dcxvXylVl90zvwpTAfGN9tMUaXJV+6rUBGdJeX IlSHtkjYiXdowew3xWt2IeHO569hVSZXgIf8VVQHF9N3Bl7xgejJHEGTuW32nxpr76Kr UgsTh14JkFRF7CsTDeQAkDvMolB0PglexQa1HLqtIoKVfMpI9ieq/SxC/o9fdA17oOx4 cWDq59KqABVIrVOJaZnYoYrJYyDXF9OE67Su/5AJB2ekp8XOvs8YOWchqknXIiXX4yYT voS5yHSJ67fy/3fmnCUGPwQ5NaOHbY9kCl91HvWTRTMh27wqMy4NZovJofuKq+X8GYLJ OnmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xYNeUbasf66NuWbP1g4BVnra6eiuMLOJKZxS1yFyPJc=; b=MRv1B06S9z47Ppjfydb810ZiewgyPdD9H1PvI9R6+bfE8sqO9NVJdH0aQ8E0t+YaKB SSvdW0AN9693S+id5cWZi9dkUnZnrAkf/WoJ29ukU2uCTM4oBE54xRevaX1k4S03q/AW pamEJfK7EP7kTDFisMxuli3U2qQVu9QKj8tWrEnR+Q6F4Z3oxGkvNC1rGzaldUeDNCdq 50UMWJXtjZUyf2KIe5Muq0Z4H3eIRnLH54uSWQKXBG/XnIB0jBLE80GXIW7wR2GqYIVS MvSvHUNQ+eYMAXLrpSJny/TmHeBR5i5C5kZn7m6ENGQhqSH0XXZOEuGkRlGLfx+XGA9p 2XAA== X-Gm-Message-State: ALyK8tI5302AUL28AVWHZihiECqcXYsHWmyWVPOTCTnGzYYyTEugpbPrfLIb7TxDhz2dBgsQBoNFSpfZ+aTY6w== X-Received: by 10.36.21.65 with SMTP id 62mr11821594itq.20.1469041774635; Wed, 20 Jul 2016 12:09:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.200.71 with HTTP; Wed, 20 Jul 2016 12:09:34 -0700 (PDT) In-Reply-To: References: From: Ryan Stone Date: Wed, 20 Jul 2016 15:09:34 -0400 Message-ID: Subject: Re: in_broadcast() called for almost every packet in ip_output() To: Drew Gallatin Cc: freebsd-transport@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions of transport level network protocols in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 19:09:36 -0000 On Wed, Jul 20, 2016 at 3:00 PM, Drew Gallatin wrote: > I'd certainly prefer not to add any overhead. Properly managing this (and > other similar) lists is a job for some lightweight lifecycle based > mechanism like concurrency kit or rcu. > > Unless you have a solid reason to fix it, I'd suggest just adding the > locking commented out (the way rwatson did with IN_IFADDR_RLOCK in > ip_input(), so that the next person to trip over it will know what's going > on. > > Drew > I'm not clear on the details, but we have some internal tests that were provoking this exact crash after a couple of days of stress testing. I believe that the actual fix would involve caching the result in the pcb. When the endpoint is already known, there's no reason to check for a broadcast packet on every single packet. On a system that uses a large number of IP addresses on an interface (e.g. for jails) the overhead of just iterating over the list is going to add up no matter what synchronization mechanism you use.