Hi everyone,
10 years after lartc.org I decided to document a little bit more of Linux
networking, and I hope I got it right. This email asks for your help in
making sure.
Recently I attempted to use IP_TRANSPARENT as outlined in
https://www.kernel.org/doc/Documentation/networking/tproxy.txt but
On Mon, Feb 19, 2007 at 03:56:23PM -0800, Stephen Hemminger wrote:
Linux 2.6.20-rc4 appears to take 4 microseconds on my P4 3GHz for a
non-blocking UDPv4 recvfrom() call, both on loopback and ethernet.
Linux 2.6.18 on my 64 bit Athlon64 3200+ takes a similar amount of time.
recvfrom
On Tue, Feb 20, 2007 at 11:50:13AM +0100, Andi Kleen wrote:
P4s are pretty slow at taking locks (or rather doing atomical operations)
and there are several of them in this path. You could try it with a UP
kernel. Actually hotunplugging the other virtual CPU should be sufficient
with recent
On Tue, Feb 20, 2007 at 07:41:25PM +0300, Evgeniy Polyakov wrote:
It can be recvfrom only problem - syscall overhead on my p4 (core duo,
debian testing) is bout 300 usec - to test I ran read('dev/zero', data,
0) in a loop.
nsec I assume?
The usec numbers for read(fd, c, 0) where fd is
On Tue, Feb 20, 2007 at 09:48:59PM +0300, Evgeniy Polyakov wrote:
Likely first overhead related to cache population or gamma-ray radiation.
If it happens only one (it does in my test), then everything is ok I
think. Bert, how frequently you get that long recvfrom()?
I have plotted the average
On Tue, Feb 20, 2007 at 02:40:40PM -0500, Benjamin LaHaise wrote:
Make sure your system is idle. Userspace bloat means that *lots* of idle
activity occurs in between timer ticks on recent distributions -- all those
You hit the nail on the head. I had previously measured with X shut down,
On Tue, Feb 20, 2007 at 02:02:00PM -0800, Rick Jones wrote:
The slope appears to be flattening-out the farther out to the right it
goes. Perhaps that is the length of time it takes to take all the
requisite cache misses.
The rate of flattening out appears to correlate with the number of
Hi people,
I'm trying to save people the cost of buying extra servers by making
PowerDNS (GPL) ever faster, but I've hit a rather fundamental problem.
Linux 2.6.20-rc4 appears to take 4 microseconds on my P4 3GHz for a
non-blocking UDPv4 recvfrom() call, both on loopback and ethernet.
Linux
On Sun, Dec 10, 2006 at 03:37:27PM -0600, Larry Finger wrote:
casted to (void*). This compiled correctly but resulted in a
softlock, because mutex_lock was called with the wrong memory
address. The patch fixes the problem. Another issue was a wrong
(quickly, between christmas dinner
On Sun, Dec 24, 2006 at 09:51:50AM -0600, Larry Finger wrote:
This is a heads-up for anyone wishing to use bcm43xx-softmac on Linus's git
tree, which is now at
v2.6.20-rc2. There are two serious bugs in that code. Fixes are found below.
For some reason your patch does not apply to stock
On Tue, Oct 31, 2006 at 11:01:01PM +0100, [EMAIL PROTECTED] wrote:
When I use sendmsg to send descriptors from one process to another using
unix-sockets I need to include at least one byte of normal data for the
descriptors to be send (using the iovec structure). The same code worked
W. R.
On Thu, Oct 26, 2006 at 02:51:51PM +0400, Evgeniy Polyakov wrote:
Benchmark uses 128 bytes sending/receiving per syscall (no latency
checks, only throughput.
Receiving CPU usage is 3 times less (90% socket code vs. 30%
Sending CPU usage is 5 times less (upto 50% vs. upto 10%).
Wow. I
Stephen,
I've applied both of your patches
(http://marc.theaimsgroup.com/?l=linux-netdevm=115878447914612w=2
and
http://marc.theaimsgroup.com/?l=linux-netdevm=115878448125216w=2
) and tried to break them, but it now appears to do the right thing in all
cases, even when malforming the .config by
On Tue, Sep 19, 2006 at 04:23:55PM -0700, Stephen Hemminger wrote:
Okay, build testing all the possibilities now, answer by morning..
Please boot some of them as well - I can see a kernel that really wants to
load bic at boot time but can't find it.
Bert
--
http://www.PowerDNS.com
On Tue, Sep 19, 2006 at 02:20:07PM -0700, David Miller wrote:
Bert's attempt was noble
It showed your desire for the truth
It was also crap :-)
Applied, but...
net/ipv4/Kconfig:607:warning: defaults for choice values not supported
It does appear to do the right thing in all cases I throw
On Tue, Sep 19, 2006 at 02:32:09PM -0700, Stephen Hemminger wrote:
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
# CONFIG_TCP_CONG_ADVANCED is not set
# CONFIG_DEFAULT_BIC is not set
# CONFIG_DEFAULT_CUBIC is not set
# CONFIG_DEFAULT_HTCP is not set
# CONFIG_DEFAULT_VEGAS is not set
#
available.
When in doubt, consider that I discovered this because my kernel was
crashing, and that this is bound to generate heaps of annoying email
otherwise.
Thanks.
Signed-off-by: bert hubert [EMAIL PROTECTED]
--- linux-2.6.18-rc7/net/ipv4/tcp_cong.c.org2006-09-18 11:42:25.0
+0200
On Mon, Sep 18, 2006 at 07:06:00AM -0700, David Miller wrote:
Any ordering scheme is wrong or unexpected for _somebody_. Look how
I agree violently. Would you agree that it would be best to have a mechanism
that explicitly sets a sane default, and does not rely on ordering?
My implementation
On Mon, Sep 18, 2006 at 11:53:09AM -0700, David Miller wrote:
What would the desired default be, 'BIC' in all cases?
And if BIC is not enabled in the configuration, then what?
As the source notes /* we'll always have reno */ . This would make the
policy: the default is bic if available,
On Sun, Sep 17, 2006 at 08:32:14AM +0900, Stephen Hemminger wrote:
By building all the possiblities into the kernel, ie. not as modules
you get the last one registered. TCP LP is probably the worst one
to use, because it is designed for bulk low priority applications.
It also is one of the
The original message Stephen reacts to below apparently never made it to the
list, it can be found here: http://ds9a.nl/tmp/module-policy.txt
Any body who builds in random stuff without thinking is being foolish.
But, if you can think of a better configuration method that isn't too
grotty,
The bad news is that I haven't yet been able to capture traces.
Once every three days or so I get a crash of 2.6.18-rc[67] which
*probably* end in tcp_ack(), but I don't have the exact dump.
My .config is indeed heavy on TCP congestion stuff:
$ zcat /proc/config.gz | grep -i tcp
It appears to be intentionally, but I don't see a reason for it.
Can you try if this patch makes it work as expected?
[PACKET]: Don't truncate non-linear skbs with mmaped IO
Non-linear skbs are truncated to their linear part with mmaped IO.
Fix by using skb_copy_bits instead of memcpy.
On Wed, Sep 13, 2006 at 08:44:21PM +0200, Patrick McHardy wrote:
Are you using TSO on the outgoing device? If so please try to log the
packet using iptables to see if it really is a TSO packet.
Good catch! I turned off TSO and things are working fine again.
Is this a known problem, should it
Hi people,
I like to use memory mapped pcap (PACKET_MMAP) since off the shelf, linux is
a tad prone to drop packets while capturing these days. It used to be lots
better at it, but right now memory mapped pcap is the only way to get things
working a bit. I've noticed this on many machines.
On Thu, Apr 20, 2006 at 12:09:55PM -0700, David S. Miller wrote:
Going all the way to the socket is a large endeavor and will require a
lot of restructuring to do it right, so expect this to take on the
order of months.
That's what you said about Niagara too :-)
Good luck!
--
On Sat, Apr 15, 2006 at 09:22:01PM +0200, Andi Kleen wrote:
And optimizing for uncommon cases (not TCP) doesn't seem too useful.
There are servers that do tens of megabits of UDP these days (think VoIP, or
in my case, DNS), so it not that uncommon.
Bert
--
http://www.PowerDNS.com
On Wed, Jan 04, 2006 at 11:36:33PM +0100, bert hubert wrote:
$ sudo ip route re default via 10.0.0.12
RTNETLINK answers: Network is unreachable
This all goes away on removing CONFIG_CC_OPTIMIZE_FOR_SIZE in the kernel
.config with the gcc prerelease Ubunty Breezy ships.
Now verifying
28 matches
Mail list logo
