Re: splxxx level?

From: Scott Long (scottl_at_freebsd.org)
Date: 08/30/04

  • Next message: M. Warner Losh: "Re: splxxx level?"
    Date: Mon, 30 Aug 2004 09:48:11 -0600
    To: Sam <sah@softcardsystems.com>
    
    

    Sam wrote:

    > Hello -
    >
    > I'm almost to testing on my AoE driver for 4.x and have
    > a question about interrupt priority levels.
    >
    > There are currently three entry points into the driver:
    >
    > a) strategy routine
    > b) network frame reception routine
    > c) timer rexmit routine
    >
    > Any of the three can diddle with the device structure
    > and thusly I need to ensure they're not running simultaneously.
    > For example, the network reception can cause a buf to be completed
    > and the rexmit timer can cause a buf to be failed.
    >
    > So, what kind of contexts are the callout, strategy, and
    > network soft interrupt called in? Which splxxx will give
    > one of them exclusive access to whatever they need?
    >
    > Just as a reality check -- I am thinking about this correct, right?
    >
    > Cheers,
    >
    > Sam
    >

    With 4.x, only one CPU can be in the kernel at a time. You won't have
    to worry about multiple processes trying to get into strategy at the
    same time and whatnot. However, you can be preempted by your interrupt
    handler or by a timeout or by a software interrupt like the netisr. I
    don't remember if your driver is for a specific piece of hardware or if
    it's a generic layer that sits in between the network interface and the
    block layer. If it's for dedicated hardware then you'll need to define
    a interrupt type in bus_setup_intr() and use that type for the spl
    (i.e. INTR_TYPE_NET translates to splnet(), INTR_TYPE_BIO translates to
    splbio(), etc).

    The safe way to go is to protect all of your critical code sections with
    the appropriate spl level regardless. spls are very cheap and can be
    set/reset from an interrupt context so there is little penalty in using
    them liberally at first and then narrowing them down later. Just make
    sure that you don't leak an spl references, and don't hold an spl for so
    long that it creates priority inversions. Since the only interrupts and
    timeouts that you'll likely be dealing with are network related,
    splnet() is probably the right one to use.

    Scott
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"


  • Next message: M. Warner Losh: "Re: splxxx level?"

    Relevant Pages

    • Re: Patch available for shared em interrupts (Re: em, bge, network problems survey.)
      ... I'm seeing some patterns here with all of the network driver problem ... Are you experiencing network hangs and/or "timeout" messages on the ... If your em device is using a shared interrupt, ... Note that this patch will not help you if you are not using the em ...
      (freebsd-stable)
    • Re: splxxx level?
      ... ::> a question about interrupt priority levels. ... ::> There are currently three entry points into the driver: ... the network reception can cause a buf to be completed ... :: the appropriate spl level regardless. ...
      (freebsd-arch)
    • Re: splxxx level?
      ... :> I'm almost to testing on my AoE driver for 4.x and have ... :> a question about interrupt priority levels. ... the network reception can cause a buf to be completed ... the appropriate spl level regardless. ...
      (freebsd-arch)
    • Re: SMSC91C111 interrupt service routine
      ... I disconnect the chip from the network and it passed ... the SMSC driver activates the ... you enable device interrupt you get an interrupt event (for frames in RX ... I tried to put a breakpoint at the beginning of the ...
      (microsoft.public.windowsce.platbuilder)
    • How to call a function in the kernel from Local APIC timer handler
      ... Therefore, I schedule a software interrupt thread, which calls my function ... > which avoids a context switch into the network stack. ... > - If your workload benefits from it, ... so you might want to consider changing thread libraries. ...
      (freebsd-current)