From owner-freebsd-net@FreeBSD.ORG Sun Jul 17 14:15:07 2011 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 20A8A1065670 for ; Sun, 17 Jul 2011 14:15:07 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ey0-f176.google.com (mail-ey0-f176.google.com [209.85.215.176]) by mx1.freebsd.org (Postfix) with ESMTP id A00E98FC08 for ; Sun, 17 Jul 2011 14:15:06 +0000 (UTC) Received: by eya28 with SMTP id 28so1990826eya.21 for ; Sun, 17 Jul 2011 07:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4pqtnzr7WIomp1GtyWw+zhoqEwvn9mhhE8RDgVssHpM=; b=aVDzM/V2sxLYetDWy+YZxX5Td+Lq/NtuIFtUEiKONIyTg+jSH9mvNRXO73Q62o2M0v DMBIHEb+vNID29F37rgkqtQklkyXqRbIqIaK7x8SdUrsx8FRUng6lzVYehKekolz1aM9 liVGuLI2FQoIVXh1y8mRtp1homq47hvMhdwOE= MIME-Version: 1.0 Received: by 10.213.21.2 with SMTP id h2mr1916512ebb.90.1310912105423; Sun, 17 Jul 2011 07:15:05 -0700 (PDT) Received: by 10.213.15.70 with HTTP; Sun, 17 Jul 2011 07:15:05 -0700 (PDT) In-Reply-To: References: <20110714154457.GI70776@FreeBSD.org> Date: Sun, 17 Jul 2011 10:15:05 -0400 Message-ID: From: Ryan Stone To: vadim_nuclight@mail.ru Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: m_pkthdr.rcvif dangling pointer problem 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: Sun, 17 Jul 2011 14:15:07 -0000 On Sun, Jul 17, 2011 at 7:59 AM, Vadim Goncharov wrote: > Ways to improve are to be found from this starting point. However, > are that +2 atomic ops per packet really so expensive? How many of > atomic ops are already on that path? Any measures? On high-performance multiqueue NICs, those two atomic ops are pretty well guaranteed to be contended every time. It's a scalability nightmare.