lkml.org 
[lkml]   [2006]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 2/4]: powerpc/cell spidernet low watermark patch.
    From
    Date
    On Fri, 2006-08-18 at 15:51 -0700, David Miller wrote:
    > From: linas@austin.ibm.com (Linas Vepstas)
    > Date: Fri, 18 Aug 2006 17:46:18 -0500
    >
    > > > We're not saying to use the RX interrupt as the trigger for
    > > > RX and TX work. Rather, either of RX or TX interrupt will
    > > > schedule the NAPI poll.
    > >
    > > And, for a lark, this is exactly what I did. Just to see.
    > > Because there are so few ack packets, there are very few
    > > RX interrupts -- not enough to get NAPI to actually keep
    > > the device busy.
    >
    > You're misreading me. TX interrupts are intended to be "enabled" and
    > trigger NAPI polls. TX IRQ enabled, enabled :-)

    Maybe be because you actually typed "disabled" in your previous
    message ? :)

    >> The idea is to use NAPI polling with TX interrupts disabled.

    > If you want to eliminate them if the kernel keeps hopping into
    > the ->hard_start_xmit() via hw interrupt mitigation or whatever,
    > that's fine. But if you do need to do TX interrupt processing,
    > do it in NAPI ->poll().

    Well, we do need to harvest descriptors of course, though I suppose that
    can be done in hard_xmit as well. I'm not sure if there is any real
    benefit in batching those.

    > > I'm somewhat disoriened from this conversation. Its presumably
    > > clear that low-watermark mechanisms are superior to NAPI.
    > > >From what I gather, NAPI was invented to deal with cheap
    > > or low-function hardware; it adds nothing to this particular
    > > situation. Why are we talking about this?
    >
    > NAPI is meant to give fairness to all devices receiving packets
    > in the system, particularly in times of high load or overload.
    >
    > And equally importantly, it allows you to run the majority of your
    > interrupt handler in software IRQ context.

    That is the most important point imho for the specific case of spidernet
    on cell.

    > This allows not only your
    > locking to be simpler, but it also allows things like oprofile to
    > monitor almost your entire IRQ processing path even with just timer
    > interrupt based oprofile profiling.
    >
    > I see you moving TX reclaim into tasklets and stuff. I've vehemently
    > against that because you wouldn't need it in order to move TX
    > processing into software interrupts if you did it all in NAPI
    > ->poll().

    Ben.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-08-19 06:35    [W:3.341 / U:0.924 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site