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] [day] [month] [year] [list]

Message-ID: <4C77EF42.6020600@candelatech.com>
Date:	Fri, 27 Aug 2010 10:00:50 -0700
From:	Ben Greear <greearb@...delatech.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [net-next 1/2] qdisc: Allow qdiscs to provide backpressure up
 the stack.

On 08/27/2010 08:59 AM, Eric Dumazet wrote:
> Le vendredi 27 août 2010 à 08:26 -0700, Ben Greear a écrit :
>
>> 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.
>
> Its not trivial at all. Actually I bet this is not possible.

Ughh, I'll quit bothering with higher level protocols then.

Dave:  Is there any reason to pursue the qdisc BUSY return code
so that it can be used for macvlans, vlans, bonding, etc, or
is that idea just DOA.

There are calls to dev_queue_xmit all over, and many don't
check return codes at all.  I could still fix those up to
free the skb when BUSY is returned.

Or, I could stay with adding a new try_dev_queue_xmit method
so that the few callers that care can deal with error codes
properly.

Based on my slightly improved understanding of how UDP and others
do queue backoff, I don't see how the changes to macvlan that
I posted could cause any additional opportunities for queue
deadlock.

If someone manages to add a qdisc to a macvlan, there could
be issues since there is no way to wake up a macvlan queue,
but that issue exists with or without my patch.

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