linux-kernel - Re: Network performance degradation from 2.6.11.12 to 2.6.16.20

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: <200609181629.53949.ak@suse.de>
Date:	Mon, 18 Sep 2006 16:29:53 +0200
From:	Andi Kleen <ak@...e.de>
To:	David Miller <davem@...emloft.net>
Cc:	master@...torb.msk.ru, hawk@...u.dk, harry@...os.washington.edu,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: Network performance degradation from 2.6.11.12 to 2.6.16.20


> 
> People who run tcpdump want "wire" timestamps as close as possible.
> Yes, things get delayed with the IRQ path, DMA delays, IRQ
> mitigation and whatnot, but it's an order of magnitude worse if
> you delay to user read() since that introduces also the delay of
> the packet copies to userspace which are significantly larger than
> these hardware level delays.  If tcpdump gets swapped out, the
> timestamp delay can be on the order of several seconds making it
> totally useless.

My proposal wasn't to delay to user read, just to do the time stamp in socket 
context. This means as soon as packet or RAW/UDP have looked up the socket and can 
check a per socket flag do the time stamp.

The only delay this would add would be the queueing time from the NIC
to the softirq. Do you really think that is that bad?

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/