Annotation of wikisrc/projects/project/if_poll.mdwn, revision 1.2

1.1       jmmv        1: [[!template id=project
                      3: title="Implement per-interface interrupt handling"
                      5: contact="""
                      6: [tech-kern](,
                      7: [tech-net](,
                      8: [board](,
                      9: [core](
                     10: """
                     12: category="networking"
                     13: difficulty="hard"
                     15: description="""
1.2     ! riastrad   16: This project proposal is a subtask of [[smp_networking]].
1.1       jmmv       17: 
                     18: The goal of this project is to implement interrupt handling at the
                     19: granularity of a networking interface.  When a network device gets an
                     20: interrupt, it could call `<iftype>_defer(ifp)` to schedule a kernel
                     21: continuation (see [[kernel_continuations]]) for that interface which could
                     22: then invoke `<iftype>_poll`.  Whether the interrupted source should be
                     23: masked depends on if the device is a DMA device or a PIO device.  This
                     24: routine should then call `(*ifp->if_poll)(ifp)` to deal with the
                     25: interrupt's servicing.
                     27: During servicing, any received packets should be passed up via
                     28: `(*ifp->if_input)(ifp, m)` which would be responsible for ALTQ or any other
                     29: optional processing as well as protocol dispatch.  Protocol dispatch in
                     30: `<iftype>_input` decodes the datalink headers, if needed, via a table
                     31: lookup and call the matching protocol's `pr_input` to process the packet.
                     32: As such, interrupt queues (e.g. `ipintrq`) would no longer be needed.  Any
                     33: transmitted packets can be processed as can MII events.  Either true or
                     34: false should be returned by `if_poll` depending on whether another
                     35: invokation of `<iftype>_poll` for this interface should be immediately
                     36: scheduled or not, respectively.
                     38: Memory allocation has to be prohibited in the interrupt routines.  The
                     39: device's `if_poll` routine should pre-allocate enough mbufs to do any
                     40: required buffering.  For devices doing DMA, the buffers are placed into
                     41: receive descripors to be filled via DMA.
                     43: For devices doing PIO, pre-allocated mbufs are enqueued onto the softc of
                     44: the device so when the interrupt routine needs one it simply dequeues one,
                     45: fills in it in, and then enqueues it onto a completed queue, finally calls
                     46: `<iftype>_defer`.  If the number of pre-allocated mbufs drops below a
                     47: threshold, the driver may decide to increase the number of mbufs that
                     48: `if_poll` pre-allocates.  If there are no mbufs left to receive the packet,
                     49: the packets is dropped and the number of mbufs for `if_poll` to
                     50: pre-allocate should be increased.
                     52: When interrupts are unmasked depends on a few things.  If the device is
                     53: interrupting "too often", it might make sense for the device's interrupts
                     54: to remain masked and just schedule the device's continuation for the next
                     55: clock tick. This assumes the system has a high enough value set for HZ.
                     56: """
                     57: ]]
                     59: [[!tag smp_networking]]

CVSweb for NetBSD wikisrc <> software: FreeBSD-CVSweb