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
| ||
|
Message-ID: <1340949008.29822.73.camel@edumazet-glaptop> Date: Fri, 29 Jun 2012 07:50:08 +0200 From: Eric Dumazet <eric.dumazet@...il.com> To: David Miller <davem@...emloft.net> Cc: netdev@...r.kernel.org, dave.taht@...il.com, codel@...ts.bufferbloat.net, therbert@...gle.com, mattmathis@...gle.com, ycheng@...gle.com, nanditad@...gle.com, ncardwell@...gle.com Subject: Re: [PATCH net-next] fq_codel: report congestion notification at enqueue time On Thu, 2012-06-28 at 22:29 -0700, David Miller wrote: > I am pretty sure the behavior in RED is intentional. > > It's a soft push back on TCP. > tcp_enter_cwr() is called the same for DROP and CN > We're taking this path when we are unable to sucessfully ECN mark a > packet. But our intention was to do so. > Hmm, problem is the sender thinks the packet was queued for transmission. ret = macvlan_queue_xmit(skb, dev); if (likely(ret == NET_XMIT_SUCCESS || ret == NET_XMIT_CN)) { struct macvlan_pcpu_stats *pcpu_stats; pcpu_stats = this_cpu_ptr(vlan->pcpu_stats); u64_stats_update_begin(&pcpu_stats->syncp); pcpu_stats->tx_packets++; pcpu_stats->tx_bytes += len; u64_stats_update_end(&pcpu_stats->syncp); } else { this_cpu_inc(vlan->pcpu_stats->tx_dropped); } NET_XMIT_CN has a lazy semantic it seems. I will just dont rely on it. -- 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
Powered by blists - more mailing lists