Re: Buffering packets in network driver (qdisc?)

Alan Cox (alan@lxorguk.ukuu.org.uk)
Sun, 15 Aug 1999 15:34:32 +0100 (BST)

> > This is fine. Be aware that if the message is issued from the context
> > of a typical socket sender you must avoid deadlocks - ie holding the memory
> > your magic message will come from.
>
> Deadlocks? More information please. It's OK to deallocate an skbuff
> right after it's been allocated, even in an interrupt handler. And the
> network stack will probably never see the packet being sent.

If the message comes from the socket not from the outside world then you
could get stuck because the socket will block when it has no memory
allocation left for sending frames. Thus you might do

alloc frame
send frame
alloc frame
send frame
alloc magic message
[sleeps]


> That makes sense. It's OK to just store a pointer to the skbuff and
> simply free it when I'm done?

The buffer is yours until you free it with dev_kfree_skb()

> >From reading from 'Linux device drivers', it's not clear when bottom
> halves are run. Either it is right after the irq exits, or on the
> next timer tick. This book only really covers 2.0.x. Has this changed?

In 2.2 it will always run after you return from the IRQ but there is still
latency there between the event and the send queue.

Alan

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