Re: [net-next 1/2] qdisc: Allow qdiscs to provide backpressure up the stack.

[Ben Greear <greearb@candelatech.com>]

On 08/26/2010 11:11 PM, David Miller wrote:
> From: Ben Greear<greearb@candelatech.com>
> Date: Thu, 26 Aug 2010 22:58:41 -0700
>
>> And if it does that, then something must know how to restart the
>> transmit logic.
>
> When SKBs get freed up, space opens up in the socket send buffer,
> waking up the process or signalling it from poll() so it can write
> more.

Seems there is still room for problems:

*  There may be zero frames already in the qdisc for this UDP connection,
    so aside from the one that failed to enqueue, none other will be freed.

*  If deleting that single SKB that was to be enqueued opens space, then it's
    not really throttling, just busy-spinning on deleting skbs, but I think
    that the wakeup heuristics won't wake the queue until it's about 1/2 full
    anyway, so that single skb isn't going to wake any queues in most cases.

I'll look through the code later today and see how much churn it would take
to support the BUSY return code from dev_queue_xmit, without adding any new
qdisc API methods.

For the trivial case, I can just kfree_skb when BUSY is returned, for the
same overall behaviour as today.  For something like UDP, I might be able
to poke the SKB back into the queue instead of freeing it.

> pktgen eliminates this whole layer of queueing and signalling, which
> is why it continually succeptible this behavior you dislike.

Proper backoff on error codes from hard_start_xmit and some wake logic
when the unerlying netdevice wakes up again fixes this.  You can make pktgen
run w/out busy spinning.  It's a big messy patch (as I coded it up)
though.

I think we could concentrate on allowing qdisc to return some sort of
congestion notification w/out always freeing the skb first, and once
that seems workable, go back to worrying about how to properly propagate
that through macvlans.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com