Date: Mon, 5 Aug 2013 19:36:22 +0200 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Adrian Chadd <adrian@freebsd.org> Cc: Giuseppe Lettieri <g.lettieri@iet.unipi.it>, net@freebsd.org, Bryan Venteicher <bryanv@daemoninthecloset.org>, Navdeep Parhar <np@freebsd.org>, current@freebsd.org Subject: Re: [net] protecting interfaces from races between control and data ? Message-ID: <CA%2BhQ2%2BgZTGmrBKTOAeFnNma4DQXbAy_y8NZrovpWqm_5BJTWhQ@mail.gmail.com> In-Reply-To: <CAJ-Vmo=Q9AqdBJ0%2B4AiX4%2BWreYuZx6VGGYw=MZ4XhMB1P2yMww@mail.gmail.com> References: <20130805082307.GA35162@onelab2.iet.unipi.it> <2034715395.855.1375714772487.JavaMail.root@daemoninthecloset.org> <CAJ-VmokT6YKPR7CXsoCavEmWv3W8urZu4eBVgKWaj9iMaVJFZg@mail.gmail.com> <CA%2BhQ2%2BhuoCCweq7fjoYmH3nyhmhb5DzukEdPSMtaJEWa8Ft0JQ@mail.gmail.com> <51FFDD1E.1000206@FreeBSD.org> <CAJ-Vmo=Q9AqdBJ0%2B4AiX4%2BWreYuZx6VGGYw=MZ4XhMB1P2yMww@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd <adrian@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BhQ2%2BgZTGmrBKTOAeFnNma4DQXbAy_y8NZrovpWqm_5BJTWhQ>