netdev - Re: about latencies

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: <20090423.170408.228280954.davem@davemloft.net>
Date:	Thu, 23 Apr 2009 17:04:08 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	dada1@...mosbay.com
Cc:	jesse.brandeburg@...el.com, cl@...ux-foundation.org,
	netdev@...r.kernel.org, mchan@...adcom.com,
	bhutchings@...arflare.com
Subject: Re: about latencies

From: Eric Dumazet <dada1@...mosbay.com>
Date: Fri, 24 Apr 2009 01:07:06 +0200

> Brandeburg, Jesse a écrit :
>> On Thu, 23 Apr 2009, Eric Dumazet wrote:
>>> We could improve this.
>>>
>>> 1) dst_release at xmit time, should save a cache line ping-pong on general case
>>> 2) sock_wfree() in advance, done at transmit time (generally the thread/cpu doing the send)
>> 
>> how much does the effect socket accounting?  will the app then fill the 
>> hardware tx ring all the time because there is no application throttling 
>> due to delayed kfree?
> 
> tx ring is limited to 256 or 512 or 1024 elements, but yes this might
> defeat udp mem accounting on sending side, unless using qdiscs...

I'm pretty sure you really can't do this.  It's been suggested
countless times in the past.

The whole point of the socket send buffer limits is to eliminate
the situation where one socket essentially hogs the TX queue of
the device.
--
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