Re: Buffering packets in network driver (qdisc?)

Martijn van Oosterhout (s3100411@student.anu.edu.au)
Mon, 16 Aug 1999 00:29:19 +1000


Alan Cox wrote:
>
> > the packets arrive from the network layer, I need to hold them
> > until this message is received.
>
> 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.

> > Is there a way to have the network layer buffer them and allow
> > the driver to extract them on demand. In dev.c it talks about
> > enqueue to do with the QoS stuff. Could this be used? Any
> > references?
>
> If you set dev->tbusy and refuse packets they will be queued for you and
> eventually spilled if you get too much congestion. When the interrupt occurs
> you can then dev->tbusy=0; mark_bh(NET_BH) and it will let rip.

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

>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?

> To reduce latency if this is an issue, remember one buffer in the card driver
> itself and when the magic message occurs send this first buffer as well.

Good idea.

Martijn van Oostehout
Australia

-
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/