From owner-freebsd-current@FreeBSD.ORG Mon Aug 5 18:46:12 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 0DE467CC; Mon, 5 Aug 2013 18:46:12 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F02A2FCA; Mon, 5 Aug 2013 18:46:11 +0000 (UTC) Received: by mail-vb0-f49.google.com with SMTP id w16so3144326vbb.8 for ; Mon, 05 Aug 2013 11:46:10 -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=6afeiJM6qdEqDg7Hhhu2/MbjauYgbQs3h+wtDMDualo=; b=HBU0qqgT82Lik9DbrYsPUPL+n1NQSAjUOy6B6ep2Nil1LdKMn94bXEfQAsqotv6bhR 7TWcrJePREOODMfQu8dULYCTb1dIOQ9oUfL0ryqc8xfaiY7d0Hxdy38bi6gRZ7tvRw9V kALV1ZG9MPpuib3rB0C89fxSkzsA6SEfDJNsBbUnMwoc1qBKUSlx8EX4x49JDduMRk3a VKceRQMC7T7uheZUdPqvjEJpoKYr8646y5IRvI2a3Yk1F7myOO01jnHLymdSaTowIeRK bS2XKrQNbS0EVPTenbylxvuQRXDBVbdJxzhbklxVtvAg5lmHxP+uogrqWvSds8QH9Mwh p41w== MIME-Version: 1.0 X-Received: by 10.58.97.238 with SMTP id ed14mr6154605veb.34.1375728370638; Mon, 05 Aug 2013 11:46:10 -0700 (PDT) Received: by 10.220.159.141 with HTTP; Mon, 5 Aug 2013 11:46:10 -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 11:46:10 -0700 Message-ID: Subject: Re: [net] protecting interfaces from races between control and data ? From: Jack Vogel To: Luigi Rizzo Content-Type: multipart/mixed; boundary=089e013a1666d6e88d04e337b81a 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 18:46:12 -0000 --089e013a1666d6e88d04e337b81a Content-Type: text/plain; charset=ISO-8859-1 What do you think about this change? Cheers, Jack On Mon, Aug 5, 2013 at 10:58 AM, Luigi Rizzo wrote: > On Mon, Aug 5, 2013 at 7:49 PM, Jack Vogel wrote: > >> Sigh, this ends up being ugly I'm afraid. I need some time to look at >> code and think about it. >> >> > actually the intel drivers seem in decent shape, > especially if we reuse IFF_DRV_RUNNING as the reset flag > and the core+queue lock in the control path. > > cheers > luigi > > > >> 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" >>> >> >> > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > --089e013a1666d6e88d04e337b81a Content-Type: application/octet-stream; name="quiesce.diff" Content-Disposition: attachment; filename="quiesce.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hk012dni0 UHJveHlDaGFpbnMtMy4xIChodHRwOi8vcHJveHljaGFpbnMuc2YubmV0KQpJbmRleDogaXhnYmUu Ywo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSBpeGdiZS5jCShyZXZpc2lvbiAyNTM5NjUpCisrKyBpeGdiZS5jCSh3 b3JraW5nIGNvcHkpCkBAIC0xMDczLDYgKzEwNzMsNyBAQAogCiAJbXR4X2Fzc2VydCgmYWRhcHRl ci0+Y29yZV9tdHgsIE1BX09XTkVEKTsKIAlJTklUX0RFQlVHT1VUKCJpeGdiZV9pbml0X2xvY2tl ZDogYmVnaW4iKTsKKwlpeGdiZV9xdWllc2NlX3F1ZXVlcyhhZGFwdGVyKTsKIAlody0+YWRhcHRl cl9zdG9wcGVkID0gRkFMU0U7CiAJaXhnYmVfc3RvcF9hZGFwdGVyKGh3KTsKICAgICAgICAgY2Fs bG91dF9zdG9wKCZhZGFwdGVyLT50aW1lcik7CkBAIC0xMzM2LDcgKzEzMzcsMjYgQEAKIAlyZXR1 cm47CiB9CiAKKy8qCisqKiBNYWtlIHN1cmUgYWxsIHF1ZXVlcyBoYXZlIHNlZW4gSUZGX0RSVl9S VU5OSU5HCisqKiBpcyBjbGVhcmVkIGFuZCBzdG9wIHByb2Nlc3NpbmcuCisqLworc3RhdGljIGlu bGluZSB2b2lkCitpeGdiZV9xdWllc2NlX3F1ZXVlcyhzdHJ1Y3QgYWRhcHRlciAqYWRhcHRlcikK K3sKKwlzdHJ1Y3QgaWZuZXQgICAqaWZwID0gYWRhcHRlci0+aWZwOworCXN0cnVjdCB0eF9yaW5n CSp0eHIgPSBhZGFwdGVyLT50eF9yaW5nczsKKwlzdHJ1Y3QgcnhfcmluZyAqcnhyID0gYWRhcHRl ci0+cnhfcmluZ3M7CiAKKwlpZnAtPmlmX2Rydl9mbGFncyAmPSB+SUZGX0RSVl9SVU5OSU5HOwor CWZvciAoaW50IGkgPSAwOyBpIDwgYWRhcHRlci0+bnVtX3F1ZXVlczsgaSsrLCByeHIrKywgdHhy KyspIHsKKwkJSVhHQkVfVFhfTE9DSyh0eHIpOworCQlJWEdCRV9UWF9VTkxPQ0sodHhyKTsKKwkJ SVhHQkVfUlhfTE9DSyhyeHIpOworCQlJWEdCRV9SWF9VTkxPQ0socnhyKTsKKwl9Cit9CisKIC8q CiAqKgogKiogTVNJWCBJbnRlcnJ1cHQgSGFuZGxlcnMgYW5kIFRhc2tsZXRzCg== --089e013a1666d6e88d04e337b81a--