[ofa-general] ***SPAM*** Re: [ewg] Re: Continue of "defer skb_orphan() until irqs enabled"

[Vladimir Sokolovsky]

On Sun, 2008-09-28 at 18:09 +0300, Moni Shoua wrote:
> Vladimir Sokolovsky wrote:
> > Olga Shern (Voltaire) wrote:
> >> Hi Eli,
> >>
> >> We also want to run regression tests with this patch.
> >> Please let me know when OFED daily build will include it.
> >>
> >> Thanks
> >> Olga
> > 
> > Hi Olga,
> > OFED-1.4-20080928-0756.tgz includes this patch.
> > 
> > Regards,
> > Vladimir
> > _______________________________________________
> > ewg mailing list
> > ewg at lists.openfabrics.org
> > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
> > 
> Which commit is it in OFED tree?

commit 47595f49915ac51116916c640f3c0d98df521789
Author: Roland Dreier <rolandd at cisco.com>
Date:   Sun Sep 28 14:58:30 2008 +0300

    IPoIB: Continue of "defer skb_orphan() until irqs enabled"
    
    Instead of trying to rely on some complicated and
    fragile reasoning about when some race might occur, let's just do what
    we want to do anyway and get rid of LLTX.  We change from priv->tx_lock
    (taken with IRQ disabling) to netif_tx_lock (taken on with
    BH-disabling).  And then we can keep the skb_orphan in the place it is,
    since our xmit routine runs with IRQs enabled.
    
    Most of this patch is just compensating for the fact that the tx_lock
    regions are now IRQ-enabled, and so we have to convert places that take
    priv->lock to disable IRQs too.
    
    If we could change ipoib_cm_rx_event_handler to not need priv->lock,
    then we could change priv->lock to a BH-disabling lock too and simplify
    things a bit further.
    
    I've tested this patch some in both datagram and connected mode with a
    kernel with lockdep and other debugging enabled, so it is at least
    somewhat sane.  However more stress testing would definitely be helpful
    if we want to put this in 2.6.28.  Also it would be interesting to see
    if there are any performance effects.
    
    Signed-off-by: Roland Dreier <rolandd at cisco.com>