From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 17:49:16 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6C19BC05; Mon, 5 Aug 2013 17:49:16 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DEC7B2B89; Mon, 5 Aug 2013 17:49:15 +0000 (UTC) Received: by mail-ve0-f172.google.com with SMTP id oz10so3461306veb.17 for ; Mon, 05 Aug 2013 10:49:15 -0700 (PDT) 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=D2+WuzNylDlrVMC06bwGlyCSnDekeP0XfKz+Pa93Yl4=; b=nIFFGrcckToaxZY3qQFYcX4tffziKnp2PPzwie3r+uzqDQFlQ44uuXcxFoqe9txZsg thCq0HR83GikytJ596Q1wK8GHvHTZ9ON2M+X06z3XDs//PcyMB+lBNcBoGuzngZP/6QL GWrYotUgeuCoP3nYrNMAZqDvWez+hP6Hr/Pphb85Hpl5GEvK7u8q5NtfD1s9/eoiSTiR M09l/k5XYV1Zkl0uuqrguhhtGBUIaqUISYGJDBkmLdggX17oIHqCgdQYLWTCobA4L7Uy WfJYcyXvHALgqERdUaw4ocO7TFvawJ8kEr4HuiTzAlEaYsMPaoq4XVCfU5iXYTIFW+kT 2DMg== MIME-Version: 1.0 X-Received: by 10.52.117.174 with SMTP id kf14mr5128392vdb.26.1375724955058; Mon, 05 Aug 2013 10:49:15 -0700 (PDT) Received: by 10.220.159.141 with HTTP; Mon, 5 Aug 2013 10:49:14 -0700 (PDT) In-Reply-To: References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <51FFDD1E.1000206@FreeBSD.org> Date: Mon, 5 Aug 2013 10:49:14 -0700 Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Jack Vogel To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Adrian Chadd , FreeBSD current mailing list , Bryan Venteicher , Navdeep Parhar , net@freebsd.org, Giuseppe Lettieri X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 17:49:16 -0000 Sigh, this ends up being ugly I'm afraid. I need some time to look at code and think about it. Jack On Mon, Aug 5, 2013 at 10:36 AM, Luigi Rizzo wrote: > On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd wrote: > > > I'm travelling back to San Jose today; poke me tomorrow and I'll brain > > dump what I did in ath(4) and the lessons learnt. > > > > The TL;DR version - you don't want to grab an extra lock in the > > read/write paths as that slows things down. Reuse the same per-queue > > TX/RX lock and have: > > > > * a reset flag that is set when something is resetting; that says to > > the queue "don't bother processing anything, just dive out"; > > * 'i am doing Tx / Rx' flags per queue that is set at the start of > > TX/RX servicing and finishes at the end; that way the reset code knows > > if there's something pending; > > * have the reset path grab each lock, set the 'reset' flag on each, > > then walk each queue again and make sure they're all marked as 'not > > doing TX/RX'. At that point the reset can occur, then the flag cna be > > cleared, then TX/RX can resume. > > > > so this is slightly different from what Bryan suggested (and you endorsed) > before, as in that case there was a single 'reset' flag IFF_DRV_RUNNING > protected by the 'core' lock, then a nested round on all tx and rx locks > to make sure that all customers have seen it. > In both cases the tx and rx paths only need the per-queue lock. > > As i see it, having a per-queue reset flag removes the need for nesting > core + queue locks, but since this is only in the control path perhaps > it is not a big deal (and is better to have a single place to look at to > tell whether or not we should bail out). > > cheers > luigi > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >