netdev - Re: cpu utilisation improvement when not doing netif_tx_{stop,wake}

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] [day] [month] [year] [list]

Date:	Fri, 29 Aug 2008 14:41:44 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	buytenh@...tstofly.org
Cc:	netdev@...r.kernel.org, dale@...nsworth.org, nico@....org
Subject: Re: cpu utilisation improvement when not doing
 netif_tx_{stop,wake}_queue()

From: Lennert Buytenhek <buytenh@...tstofly.org>
Date: Thu, 28 Aug 2008 18:46:38 +0200

> I.e. transmitting wire speed gigabit over a single TCP session takes
> around 90% CPU time (measured with cyclesoak) if I have the TX queue
> flow control enabled, but only 70% if I rip the TX queue flow control
> out.  (This is on a relatively underpowered ARM box.)

I bet TCP is taking over and doing the flow control for us :)

My suspicion is that TCP adjusts to the initial packet drops when the
TX queue overflows for the first time and simply does not transmit
faster than the NIC's TX queue can push things out.

I bet the TX buffer space usage for the socket and the TCP windows
used are smaller too, another huge win and something that also helps
for CPU utilization and cpu cache hit rates.

Unfortunately, for the sake of dumb protocols like UDP, this isn't
something we can do universally.  Although it is very neat!
--
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