netdev - Re: [RFC] Make TCP prequeue configurable

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: <20070928.154031.99471318.davem@davemloft.net>
Date:	Fri, 28 Sep 2007 15:40:31 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	jheffner@....edu
Cc:	shemminger@...ux-foundation.org, dada1@...mosbay.com,
	netdev@...r.kernel.org
Subject: Re: [RFC] Make TCP prequeue configurable

From: John Heffner <jheffner@....edu>
Date: Thu, 27 Sep 2007 22:26:02 -0400

> I think it really does help in case (4) with old NICs that don't do rx 
> checksumming.  I'm not sure how many people really care about this 
> anymore, but probably some...?
> 
> OTOH, it would be nice to get rid of sysctl_tcp_low_latency.

I know most high end apps use poll() so won't sleep in recvmsg()
directly, but occasisionally they will, and even those that have a
poll() triggered recvmsg() will run the backlog and do prequeue if
packets arrive while they are processing the existing receive packets
which is quite common.

So for any app that ends up doing a prequeue it's a win because there
is the issue of scheduling and cpu usage charging.

If the ACK's are coming out of the stack at the rate that the
application can pull data out of the receive queue, and no faster,
this will pace the sender to send precisely how fast the receiver can
get onto the cpu depending upon load.

Furthermore, prequeue puts the stack input processing work into user
context, which means that the users will be charged more fairly for
the work that is done for them.

When packets get fully processed in softirq context, that's bad
because this is cpu usage which doesn't get charged to the user, and
for TCP input processing this cpu usage is non-trivial and is
multiplied by packet count.
-
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