Date: Mon, 5 Aug 2013 11:46:10 -0700 From: Jack Vogel <jfvogel@gmail.com> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: Adrian Chadd <adrian@freebsd.org>, FreeBSD current mailing list <current@freebsd.org>, Bryan Venteicher <bryanv@daemoninthecloset.org>, Navdeep Parhar <np@freebsd.org>, net@freebsd.org, Giuseppe Lettieri <g.lettieri@iet.unipi.it> Subject: Re: [net] protecting interfaces from races between control and data ? Message-ID: <CAFOYbck9QU2_HO-XQkyNyQ%2B49w0892SE9FbdE3VwNyrDhC3mZA@mail.gmail.com> In-Reply-To: <CA%2BhQ2%2BhAcyi=uFcOLV1YNMfDAmdhJoTtqtgpb=R_-RKSmWX9FQ@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> <CA%2BhQ2%2BgZTGmrBKTOAeFnNma4DQXbAy_y8NZrovpWqm_5BJTWhQ@mail.gmail.com> <CAFOYbckJaZYQj2D4k41Nmjm9urue9_CDcdQ3yhRddWx0SzXE6g@mail.gmail.com> <CA%2BhQ2%2BhAcyi=uFcOLV1YNMfDAmdhJoTtqtgpb=R_-RKSmWX9FQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] What do you think about this change? Cheers, Jack On Mon, Aug 5, 2013 at 10:58 AM, Luigi Rizzo <rizzo@iet.unipi.it> wrote: > On Mon, Aug 5, 2013 at 7:49 PM, Jack Vogel <jfvogel@gmail.com> 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 <rizzo@iet.unipi.it> wrote: >> >>> 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 >>> >>> _______________________________________________ >>> 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) > -----------------------------------------+------------------------------- > [-- Attachment #2 --] ProxyChains-3.1 (http://proxychains.sf.net) Index: ixgbe.c =================================================================== --- ixgbe.c (revision 253965) +++ ixgbe.c (working copy) @@ -1073,6 +1073,7 @@ mtx_assert(&adapter->core_mtx, MA_OWNED); INIT_DEBUGOUT("ixgbe_init_locked: begin"); + ixgbe_quiesce_queues(adapter); hw->adapter_stopped = FALSE; ixgbe_stop_adapter(hw); callout_stop(&adapter->timer); @@ -1336,7 +1337,26 @@ return; } +/* +** Make sure all queues have seen IFF_DRV_RUNNING +** is cleared and stop processing. +*/ +static inline void +ixgbe_quiesce_queues(struct adapter *adapter) +{ + struct ifnet *ifp = adapter->ifp; + struct tx_ring *txr = adapter->tx_rings; + struct rx_ring *rxr = adapter->rx_rings; + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; + for (int i = 0; i < adapter->num_queues; i++, rxr++, txr++) { + IXGBE_TX_LOCK(txr); + IXGBE_TX_UNLOCK(txr); + IXGBE_RX_LOCK(rxr); + IXGBE_RX_UNLOCK(rxr); + } +} + /* ** ** MSIX Interrupt Handlers and Tasklets
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFOYbck9QU2_HO-XQkyNyQ%2B49w0892SE9FbdE3VwNyrDhC3mZA>