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
| ||
|
Date: Mon, 23 Apr 2012 22:37:26 +0200 From: Eric Dumazet <eric.dumazet@...il.com> To: David Miller <davem@...emloft.net> Cc: rick.jones2@...com, netdev@...r.kernel.org, therbert@...gle.com, ncardwell@...gle.com, maze@...gle.com, ycheng@...gle.com, ilpo.jarvinen@...sinki.fi Subject: Re: [PATCH 2/2 net-next] tcp: sk_add_backlog() is too agressive for TCP On Mon, 2012-04-23 at 16:01 -0400, David Miller wrote: > Hmmm... why don't we just acknowledge reality and special case ACKs? > Yes why not. > If a TCP packet is dataless we should just let it go through no matter > what and with no limits. It is by definition transient and will not > get queued up into the socket past this backlog stage. > Even being transient we need a limit. Without copybreak, an ACK can cost 2048+256 bytes. In my 10Gbit tests (standard netperf using 16K buffers), I've seen backlogs of 300 ACK packets... > This proposed patch allows non-dataless packets to eat more space in > the backlog, thus the concern and slight pushback. And from another > perspective, having the stack process data packets which will just > get dropped when we try to attach it to the receive queue is just > wasted work. We could try to coalesce ACKs before backlogging them. I'll work on this. Thanks -- 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