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]

Message-ID: <4C774B8F.2030805@candelatech.com>
Date:	Thu, 26 Aug 2010 22:22:23 -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 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?

What logic wakes up the socket transmit logic for those other 4
packets?

For sch_generic, it never returns NET_XMIT_CN at all..it just returns
NET_XMIT_DROP and deletes the passed-in skb.  Others, such as sch_fifo
drop the oldest pkt, keep the one passed in, and returns NET_XMIT_CN,
so it could not benefit from my patch.

>> One thing that really bothers me about the current qdisc stuff is that
>> it just frees the packet when it cannot accept it.
>
> Without the drop, things like RED simply would not work.

Even if RED could never work, the sch_generic can.

>> This *should* allow us to better throttle UDP sockets without
>> dropping as many packets on the sending side, and would probably
>> help TCP as well.
>
> UDP is well throttled by the socket send buffer.
>
> The only problematic case is pktgen and it's an abberation and
> an obscure case.  It's in fact trying to bypass all of the
> queueing and accounting the stack normally makes use of.

 From looking at upstream code, it seems that pktgen does the
right thing when NET_XMIT_CN or NET_XMIT_DROP is returned,
as long as you don't mind busy-spinning and perhaps some
accounting errors (NET_XMIT_CN doesn't mean *your* pkt was
deleted, just that somebody's packet was).

For accounting purposes, it would still be nice to get
NET_TX_BUSY because then you can just retry the packet
and you know that your packet was not transmitted or dropped.

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