[Top] [All Lists]

Re: lapb module irq context problems

To: davem@xxxxxxxxxx
Subject: Re: lapb module irq context problems
From: Henner Eisen <eis@xxxxxxxxxxxxx>
Date: Sat, 23 Dec 2000 00:02:49 +0100
Cc: netdev@xxxxxxxxxxx
In-reply-to: <200012201820.KAA10981@xxxxxxxxxxxxxxx> (davem@xxxxxxxxxx)
References: <200012192332.AAA11827@xxxxxxxxxxxxx> <200012201820.KAA10981@xxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
>>>>> "David" == David S Miller <davem@xxxxxxxxxx> writes:

    David> I would recommend to do #3 but make it identical to
    David> lapb_data_received() except that it explicitly uses
    David> kfree_skb_irq().  Let the core networking "defer to

Yes. My idea of #3 b was that lapb_data_received_irq() is of equal type
as lapb_data_received(). lapb_data_received_irq() would just call
netif_rx() on a special `lapb_irq' pseudo device, and a special packet
handler would receive all these packet and just pass them to the
current lapb_data_received().

Code which already calls lapb_data_received() from soft irq does not need
to be changed. Only code that currently calls lapb_data_received()
from hard irq needs to be changed to use the new lapb_data_received_irq()
interface. The output related interface to the lapb module is usually
called on behalf of dev->hard_start_xmit (which is already soft irq context).
The same hold for the timer events.

Thus, once the `hard irq' drivers are converted to the new interface,
there will no longer be any part in the lapb protocol engine that is
called from hard irq. Thus, no `kfree_skb()' needs to be changed
to `kree_skb_irq()'. And code which already uses the lapb module
from soft irq will not be penalized by the additional kfree_skb_any()

As the input path of the lapb protocol is not trivial (it could even
trigger additional output to acknowledge the revied frame), moving
the whole protocol processing from hard irq to soft irq might be a
good idea anyway.


<Prev in Thread] Current Thread [Next in Thread>