Re: flowcontrol on IP stack: NIC<->IP<->own_stack<->kernel

From: Andi Kleen (ak@suse.de)
Date: Sat Jun 03 2000 - 14:53:43 EST


On Fri, Jun 02, 2000 at 11:05:00PM +0300, Janne Pänkälä wrote:
> I have problem with module that clones skb pckages and stores them.
>
> When sending UDP streams to machine it would run out of memory because
> package storage doesn't have time to handle packages in it when NIC
> is pushing packets in to IP stack and from there to module like no
> tomorrow.
>
> Is there a way to access IP's flow control <netdev_max_backlog> and that
> way let module have time to empty itself.
>
> ----< net/core/dev.c >----
> if (backlog.qlen <= netdev_max_backlog) {
> if (backlog.qlen) {
> if (netdev_dropping == 0) {
> ----
> I see that there is <netdev_dropping> but unfortunately it does not help
> much since it first checks <backlog.qlen> which is zero since we nuke all
> packages after we have cloned & stored them.
>
> So what I do now is to drop all packages I get when I have stored
> something like 30 packages. This sucks big time and kills performance
> totally.
>
> I'd need a way to tell lower level (or fool it) that there is stuff to be
> processed in IP please do not gimme more stuff.
>
> As <netdev_dropping> is unusable for this is there lock or similiar that
> can be "legally" used to disable input to IP stack. (skb_queue_lock?) or
> will there be need for ugly hack that can have no excuses ;> .

netdev_dropping has some more problems, e.g. it does not seem to work well
for gigabit routing because it drops too much.

You need some hack. Best would be a call into the device driver to make
it turn off its interrupts. Such a thing is actually planned for a long
time now (to prevent the 40 byte UDP packets in full blast -- machine
dead in livelock DoS), but the device driver interface is quite some work.

In the meantime you could add some flag that is checked in netif_rx

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.rutgers.edu



This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:32 EST