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 for Android: free password hash cracker in your pocket

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

Message-ID: <4C775411.1000302@candelatech.com>
Date:	Thu, 26 Aug 2010 22:58:41 -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 10:36 PM, David Miller wrote:
> From: Ben Greear<greearb@...delatech.com>
> Date: Thu, 26 Aug 2010 22:22:23 -0700
>
>> On 08/26/2010 09:34 PM, David Miller wrote:
>>> From: Ben Greear<greearb@...delatech.com>
>>> Date: Thu, 26 Aug 2010 21:14:39 -0700
>>>
>>>> I'll look into the NET_XMIT_CN, but if that propagates backpressure up
>>>> through mac-vlan, then something must know how to re-start the tx
>>>> logic.
>>>
>>> It doesn't need to, as it drops and frees up the packet.
>>
>> If there were 5 pkts in the socket buffer, and the attempt to
>> send the first one caused NET_XMIT_CN, then
>> based on your comment below about UDP being throttled, I assume
>> the other 4 are kept until later?
>
> It only has an effect on TCP, it causes it to decrease the
> congestion window limits.
>
> I did not state that it had any effect on UDP.  Just because I
> talk about UDP later in my email doesn't mean the two things
> are related.

Ok, but you did state that UDP is well throttled.

To me that implies some backpressure will fill up socket transmit buffers
and slow down user-space transmit if the local network device cannot handle
the load.  And if it does that, then something must know how to restart the
transmit logic.

Maybe it's well throttled on real devices by the sched logic and
the netdev-wake-queue logic but just not on vlans?

Either way, it would be nice if we could throttle w/out having to drop
packets, so a way for certain sched types to return a BUSY code and not
delete the skb still seems useful, and not fundamentally different from
handling NET_XMIT_CN.

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