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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 Aug 2010 08:26:49 -0700
From:	Ben Greear <greearb@...delatech.com>
To:	David Miller <davem@...emloft.net>
CC:	netdev@...r.kernel.org
Subject: Re: [net-next 1/2] qdisc: Allow qdiscs to provide backpressure up
 the stack.

On 08/26/2010 11:11 PM, David Miller wrote:
> From: Ben Greear<greearb@...delatech.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@...delatech.com>
Candela Technologies Inc  http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html