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 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
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,
b
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 avera
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 /d
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 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.
> > r
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 2.6.
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 2.6
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 preparat
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. S
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 curr
Stephen,
I've applied both of your patches
(http://marc.theaimsgroup.com/?l=linux-netdev&m=115878447914612&w=2
and
http://marc.theaimsgroup.com/?l=linux-netdev&m=115878448125216&w=2
) and tried to break them, but it now appears to do the right thing in all
cases, even when malforming the .config
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: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
# CON
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
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 availabl
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
rest is still
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-1
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, t
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 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
CONFIG_INET_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.
Howeve
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!
--
http://www.
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 03:46:21PM -0800, David S. Miller wrote:
> > Now verifying if this is fixed in gcc 4.0.2.
Plain, non-Ubuntu prerelease, gcc 4.0.2 does not exhibit this problem, even
with -Os.
Problem solved.
--
http://www.PowerDNS.com Open source, database driven DNS Software
htt
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 i
On Mon, Aug 15, 2005 at 01:43:23PM -0700, David S. Miller wrote:
> But that's still going to be 48-bits less protection than
> TCP gives you. TCP has a sequence number (32-bits) and
> a timestamp (another 32-bits) as well as the saddr/daddr/
> sport/dport 48-bit tuple.
I hate it as well hehe. A
Dave,
Thanks for the prompt reply, much appreciated.
On Mon, Aug 15, 2005 at 01:25:10PM -0700, David S. Miller wrote:
> UDP does not have the same kind of vulnerability from port
> number guessing. In fact, UDP is extremely vulnerable for
Yes it does. Nameservers also need to send outgoing pa
31 matches
Mail list logo
