Hi Jesse,
It's good to be talking directly to one of the e1000 developers and
maintainers. Although at this point I am starting to think that the
issue may be TCP stack related and nothing to do with the NIC. Am I
correct that these are quite distinct parts of the kernel?
Yes, quite.
OK.
Herbert Xu wrote:
On Wed, Jan 30, 2008 at 10:14:46AM +0100, Marco Berizzi wrote:
Sorry for bother you again.
I have applied to 2.6.24, but ipcomp doesn't work anyway.
I have patched a clean 2.6.24 tree and I did a complete
rebuild.
With tcpdump I see both the esp packets going in/out
Hello,
A question about XFRM_POLICY_ICMP:
I had tried to understand this check in __xfrm_lookup() method in
net/xfrm/xfrm_policy.c (the recent 2.6 git dave miller tree):
...
...
if ((flags XFRM_LOOKUP_ICMP) !(policy-flags
XFRM_POLICY_ICMP))
goto error;
...
Hi Sangtae,
Thanks for joining this discussion -- it's good to a CUBIC author and
expert here!
In our application (cluster computing) we use a very tightly coupled
high-speed low-latency network. There is no 'wide area traffic'. So
it's hard for me to understand why any networking
Bruce Allen [EMAIL PROTECTED] writes:
Important note: we ARE able to get full duplex wire speed (over 900
Mb/s simulaneously in both directions) using UDP. The problems occur
only with TCP connections.
Another issue with full duplex TCP not mentioned yet is that if TSO is used
the output
Hi Andi!
Important note: we ARE able to get full duplex wire speed (over 900
Mb/s simulaneously in both directions) using UDP. The problems occur
only with TCP connections.
Another issue with full duplex TCP not mentioned yet is that if TSO is used
the output will be somewhat bursty and
Adrian Bunk wrote:
sysctl_tr_rif_timeout can now become static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: Pavel Emelyanov [EMAIL PROTECTED]
---
e5accd81b924224d40a3f38204c08cf6896ed79b
diff --git a/net/802/tr.c b/net/802/tr.c
index 3f16b17..18c6647 100644
---
Adrian Bunk wrote:
struct ipv4_devconf can now become static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: Pavel Emelyanov [EMAIL PROTECTED]
---
include/linux/inetdevice.h |2 --
net/ipv4/devinet.c |2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
Adrian Bunk wrote:
This patch makes the needlessly global nf_ct_path[] static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: Pavel Emelyanov [EMAIL PROTECTED]
Thanks, Adrian!
---
6396fbcebe3eb61f7e6eb1a671920a515912b005
diff --git a/net/netfilter/nf_conntrack_standalone.c
Adrian Bunk wrote:
Commit 42a73808ed4f30b739eb52bcbb33a02fe62ceef5
([RAW]: Consolidate proc interface.) did not only change raw6_seq_ops
(including adding 3 EXPORT_SYMBOL_GPL's to net/ipv4/raw.c for accessing
functions from there), it also removed the only user of raw6_seq_ops...
The commit
David Miller wrote:
From: Pavel Emelyanov [EMAIL PROTECTED]
Date: Thu, 24 Jan 2008 16:15:13 +0300
The comment about race free view of the set of network
namespaces was a bit hasty. Look (there even can be only
one CPU, as discovered by Alexey Dobriyan and Denis Lunev):
...
Instead, I
yesterday Adrian Bunk noticed, that the commit
commit 42a73808ed4f30b739eb52bcbb33a02fe62ceef5
Author: Pavel Emelyanov [EMAIL PROTECTED]
Date: Mon Nov 19 22:38:33 2007 -0800
is somewhat strange. Basically, the commit is obviously wrong as the
content of the /proc/net/raw6 is incorrect due to
There is no need to use 128 bytes on the stack at all. Clean the code in
the IPv6 style.
Signed-off-by: Denis V. Lunev [EMAIL PROTECTED]
---
net/ipv4/raw.c | 24 +++-
1 files changed, 7 insertions(+), 17 deletions(-)
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index
The address of IPv6 raw sockets was shown in the wrong format, from IPv4 ones.
The problem has been introduced by the
commit 42a73808ed4f30b739eb52bcbb33a02fe62ceef5
Author: Pavel Emelyanov [EMAIL PROTECTED]
Date: Mon Nov 19 22:38:33 2007 -0800
Thanks to Adrian Bunk who originally noticed the
Different hashtables are used for IPv6 and IPv4 raw sockets, so no need to
check the socket family in the iterator over hashtables. Clean this out.
Signed-off-by: Denis V. Lunev [EMAIL PROTECTED]
---
include/net/raw.h |4 +---
net/ipv4/raw.c| 12
net/ipv6/raw.c|2
From: Pavel Emelyanov [EMAIL PROTECTED]
Date: Thu, 31 Jan 2008 14:05:57 +0300
I have one more patch pending in netdev@ and some more to be sent
(cleanups, small fixes and net namespaces). Do I have to wait till
net-2.6.26, or can I start (re-)sending them while 2.6.25 merge
window is open?
On Wed, 30 Jan 2008, SANGTAE HA wrote:
On Jan 30, 2008 5:25 PM, Bruce Allen [EMAIL PROTECTED] wrote:
In our application (cluster computing) we use a very tightly coupled
high-speed low-latency network. There is no 'wide area traffic'. So it's
hard for me to understand why any
From: Denis V. Lunev [EMAIL PROTECTED]
Date: Thu, 31 Jan 2008 14:32:52 +0300
yesterday Adrian Bunk noticed, that the commit
commit 42a73808ed4f30b739eb52bcbb33a02fe62ceef5
Author: Pavel Emelyanov [EMAIL PROTECTED]
Date: Mon Nov 19 22:38:33 2007 -0800
is somewhat strange. Basically, the
I just managed to hang a 2.6.24 (+ some non network patches) kernel
with the following (non sensical) command
tc qdisc add dev eth0 root tbf rate 1000 burst 10 limit 100
No oops or anything just hangs. While I understand root can
do bad things just hanging like this seems a little extreme.
We have INET_MATCH, INET_TW_MATCH and INET6_MATCH to test
sockets and twbuckets for matching, but ipv6 twbuckets are
tested manually.
Here's the INET6_TW_MATCH to help with it.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
---
include/linux/ipv6.h|8
These two functions are the same except for what they call
to check_established and hash for a socket.
This saves half-a-kilo for ipv4 and ipv6.
add/remove: 1/0 grow/shrink: 1/4 up/down: 582/-1128 (-546)
function old new delta
__inet_hash_connect
Change to using dev_dbg() and the other dev_xxx()
macros instead of printk, and update to use the
print_mac() helper.
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
Index: linux-2.6.24-quilt1/drivers/net/ax88796.c
===
---
Here are some preparations and cleanups to enable network device/inet
address notifiers inside a namespace.
This set of patches has been originally sent last Friday. One cleanup
patch from the original series is dropped as wrong, thanks to Daniel
Lezcano.
--
To unsubscribe from this list: send
applied and tested to 2.6.24: ipcomp is working now.
As always, thanks a lot Herbert for fixing this.
Thank you too, I applied the 2 patches and it works.
Daniel
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo
net-ipv4.fib_table_hash is not freed when fib4_rules_init failed. The problem
has been introduced by the following commit.
commit c8050bf6d84785a7edd2e81591e8f833231477e8
Author: Denis V. Lunev [EMAIL PROTECTED]
Date: Thu Jan 10 03:28:24 2008 -0800
Signed-off-by: Denis V. Lunev [EMAIL
Remove error code assignment inside brackets on failure. The code looks better
if the error is assigned before condition check. Also, the compiler treats this
better.
Signed-off-by: Denis V. Lunev [EMAIL PROTECTED]
---
net/ipv4/devinet.c | 21 -
1 files changed, 8
This is required to make fib_info lookups namespace aware. In the other case
initial namespace devices are marked as dead in the local routing table
during other namespace stop.
Signed-off-by: Denis V. Lunev [EMAIL PROTECTED]
---
include/net/ip_fib.h |1 +
net/ipv4/fib_semantics.c |8
The namespace is available when required except rtm_to_ifaddr. Add
namespace argument to it.
Signed-off-by: Denis V. Lunev [EMAIL PROTECTED]
---
net/ipv4/devinet.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index
fib_sync_down can be called with an address and with a device. In reality
it is called either with address OR with a device. The codepath inside is
completely different, so lets separate it into two calls for these two
cases.
Signed-off-by: Denis V. Lunev [EMAIL PROTECTED]
---
The namespace is not available in the fib_sync_down_addr, add it
as a parameter.
Looking up a device by the pointer to it is OK. Looking up using a result
from fib_trie/fib_hash table lookup is also safe. No need to fix that at all.
So, just fix lookup by address and insertion to the hash table
macb devices are only found integrated on SoCs, so they can't be
hotplugged. Thus, the probe() and exit() functions can be __init and
__exit, respectively. By using platform_driver_probe() instead of
platform_driver_register(), there won't be any references to the
discarded probe() function after
Good morning (my TZ),
I'll try to answer all questions, hoewver if I miss something big,
please point my nose to it again.
Rick Jones wrote:
As asked in LKML thread, please post the exact netperf command used to
start the client/server, whether or not you're using irqbalanced (aka
TSO interacts badly with many queueing disciplines because they rely on
reordering packets from different streams and the large TSO packets can
make this difficult. This patch disables TSO for sockets that send over
devices with non standard queueing disciplines. That's anything but noop
or
On Thursday 31 January 2008 13:21:00 Andi Kleen wrote:
I just managed to hang a 2.6.24 (+ some non network patches) kernel
with the following (non sensical) command
Correction: the kernel was actually a git linus kernel with David's
recent merge included.
I found it's pretty easy to hang
Add the net parameter to udp_get_port family of calls and
udp_lookup one and use it to filter sockets.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
---
net/ipv4/udp.c | 25 ++---
net/ipv6/udp.c | 10 ++
2 files changed, 20 insertions(+), 15 deletions(-)
Add a net argument to inet_lookup and propagate it further
into lookup calls. Plus tune the __inet_check_established.
The dccp and inet_diag, which use that lookup functions
pass the init_net into them.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
---
include/net/inet_hashtables.h | 48
This tags the inet_bind_bucket struct with net pointer,
initializes it during creation and makes a filtering
during lookup.
A better hashfn, that takes the net into account is to
be done in the future, but currently all bind buckets
with similar port will be in one hash chain.
Signed-off-by:
Add a net argument to inet6_lookup and propagate it further.
Actually, this is tcp-v6 implementation of what was done for
tcp-v4 sockets in a previous patch.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
---
include/linux/ipv6.h |8
include/net/inet6_hashtables.h |
From: Pavel Emelyanov [EMAIL PROTECTED]
Date: Thu, 31 Jan 2008 15:40:16 +0300
Add a net argument to inet6_lookup and propagate it further.
Actually, this is tcp-v6 implementation of what was done for
tcp-v4 sockets in a previous patch.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
From: Pavel Emelyanov [EMAIL PROTECTED]
Date: Thu, 31 Jan 2008 15:41:58 +0300
Add the net parameter to udp_get_port family of calls and
udp_lookup one and use it to filter sockets.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
Applied.
--
To unsubscribe from this list: send the line
On Wed, Jan 30 2008, Dave Young wrote:
The bluetooth hci_conn sysfs add/del executed in the default workqueue.
If the del_conn is executed after the new add_conn with same target,
add_conn will failed with warning of same kobject name.
Here add btaddconn btdelconn workqueues,
flush the
In article [EMAIL PROTECTED] (at Thu, 31 Jan 2008 15:41:58 +0300), Pavel
Emelyanov [EMAIL PROTECTED] says:
Add the net parameter to udp_get_port family of calls and
udp_lookup one and use it to filter sockets.
I may miss something, but I'm afraid that I have to disagree.
Port is identified
From: YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED]
Date: Fri, 01 Feb 2008 00:11:38 +1100 (EST)
In article [EMAIL PROTECTED] (at Thu, 31 Jan 2008 15:41:58 +0300), Pavel
Emelyanov [EMAIL PROTECTED] says:
Add the net parameter to udp_get_port family of calls and
udp_lookup one and use it to
From: Pavel Emelyanov [EMAIL PROTECTED]
Date: Thu, 31 Jan 2008 15:38:15 +0300
Add a net argument to inet_lookup and propagate it further
into lookup calls. Plus tune the __inet_check_established.
The dccp and inet_diag, which use that lookup functions
pass the init_net into them.
From: Pavel Emelyanov [EMAIL PROTECTED]
Date: Thu, 31 Jan 2008 15:29:20 +0300
0/6? :-)
We have INET_MATCH, INET_TW_MATCH and INET6_MATCH to test
sockets and twbuckets for matching, but ipv6 twbuckets are
tested manually.
Here's the INET6_TW_MATCH to help with it.
Signed-off-by: Pavel
Em Thu, Jan 31, 2008 at 03:32:09PM +0300, Pavel Emelyanov escreveu:
These two functions are the same except for what they call
to check_established and hash for a socket.
This saves half-a-kilo for ipv4 and ipv6.
Good stuff!
Yesterday I was perusing tcp_hash and I think we could have the
From: Pavel Emelyanov [EMAIL PROTECTED]
Date: Thu, 31 Jan 2008 15:32:09 +0300
These two functions are the same except for what they call
to check_established and hash for a socket.
This saves half-a-kilo for ipv4 and ipv6.
add/remove: 1/0 grow/shrink: 1/4 up/down: 582/-1128 (-546)
From: Pavel Emelyanov [EMAIL PROTECTED]
Date: Thu, 31 Jan 2008 15:35:39 +0300
This tags the inet_bind_bucket struct with net pointer,
initializes it during creation and makes a filtering
during lookup.
A better hashfn, that takes the net into account is to
be done in the future, but
From: Denis V. Lunev [EMAIL PROTECTED]
Date: Thu, 31 Jan 2008 15:00:45 +0300
commit c8050bf6d84785a7edd2e81591e8f833231477e8
Author: Denis V. Lunev [EMAIL PROTECTED]
Date: Thu Jan 10 03:28:24 2008 -0800
I am fixing it up for you this time, but please do not
reference the commit this way.
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Thu, 31 Jan 2008 11:01:53 -0200
Em Thu, Jan 31, 2008 at 03:32:09PM +0300, Pavel Emelyanov escreveu:
These two functions are the same except for what they call
to check_established and hash for a socket.
This saves half-a-kilo for
Yo!
Jay Vosburgh wrote:
Benny Amorsen [EMAIL PROTECTED] wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=430391
I know what this is, I'll fix it.
do you know when this happend, so we would know which kernel is ok to
use (not to start trying blindly)?
Siim
--
To unsubscribe from
Arnaldo Carvalho de Melo wrote:
Em Thu, Jan 31, 2008 at 03:32:09PM +0300, Pavel Emelyanov escreveu:
These two functions are the same except for what they call
to check_established and hash for a socket.
This saves half-a-kilo for ipv4 and ipv6.
Good stuff!
Yesterday I was perusing
On Thu, 2008-31-01 at 13:21 +0100, Andi Kleen wrote:
I just managed to hang a 2.6.24 (+ some non network patches) kernel
with the following (non sensical) command
tc qdisc add dev eth0 root tbf rate 1000 burst 10 limit 100
No oops or anything just hangs. While I understand root can
do
-
lilsol:~# tc qdisc add dev eth0 root tbf rate 1000 burst 10 limit 100
lilsol:~# uname -a
Linux lilsol 2.6.24 #1 PREEMPT Sun Jan 27 09:22:00 EST 2008 i686
Can you try it again with current git mainline?
GNU/Linux
lilsol:~# tc qdisc ls dev eth0
qdisc tbf 8001: root rate 1000bit
Andi Kleen wrote:
-
lilsol:~# tc qdisc add dev eth0 root tbf rate 1000 burst 10 limit 100
lilsol:~# uname -a
Linux lilsol 2.6.24 #1 PREEMPT Sun Jan 27 09:22:00 EST 2008 i686
Can you try it again with current git mainline?
I'll look into it.
--
To unsubscribe from this list: send the
On Wed, 2008-30-01 at 11:31 -0200, Dzianis Kahanovich wrote:
Currently fine u32 hashkey ... at ... not work with relative offsets.
There are simpliest fix to use eat.
(sorry, v2)
Hi,
Please send me the commands you are trying to run that motivated this
patch.
cheers,
jamal
--
To
In article [EMAIL PROTECTED] (at Thu, 31 Jan 2008 05:20:07 -0800 (PST)),
David Miller [EMAIL PROTECTED] says:
The networking devices are even per-namespace already,
so you can even say that each namespace is even
physically different.
Ah, okay, we are splitting weak domains...
--yoshfuji
--
Em Thu, Jan 31, 2008 at 04:18:51PM +0300, Pavel Emelyanov escreveu:
Arnaldo Carvalho de Melo wrote:
Em Thu, Jan 31, 2008 at 03:32:09PM +0300, Pavel Emelyanov escreveu:
These two functions are the same except for what they call
to check_established and hash for a socket.
This saves
Patrick McHardy wrote:
Andi Kleen wrote:
-
lilsol:~# tc qdisc add dev eth0 root tbf rate 1000 burst 10 limit 100
lilsol:~# uname -a
Linux lilsol 2.6.24 #1 PREEMPT Sun Jan 27 09:22:00 EST 2008 i686
Can you try it again with current git mainline?
I'll look into it.
Works for me:
Benjamin Li wrote:
Signed-off-by: Benjamin Li [EMAIL PROTECTED]
---
net/8021q/vlan_dev.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 8059fa4..2fa5d68 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@
On Thu, Jan 31, 2008 at 11:25:31AM +, Ben Dooks wrote:
Change to using dev_dbg() and the other dev_xxx()
macros instead of printk, and update to use the
print_mac() helper.
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
Please send to [EMAIL PROTECTED] or [EMAIL PROTECTED], the email
Bill Fink wrote:
If the receive direction uses a different GigE NIC that's part of the
same quad-GigE, all is fine:
[EMAIL PROTECTED] ~]$ nuttcp -f-beta -Itx -w2m 192.168.6.79 nuttcp -f-beta
-Irx -r -w2m 192.168.5.79
tx: 1186.5051 MB / 10.05 sec = 990.2250 Mbps 12 %TX 13 %RX 0 retrans
rx:
Works for me:
qdisc tbf 8001: root rate 1000bit burst 10b/8 mpu 0b lat 720.0ms
Sent 0 bytes 0 pkt (dropped 9, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
Packets are dropped as expected.
I can still reproduce it on 64bit with http://halobates.de/config-qdisc
(all
The hashlimit_ipv6_mask() is called from under IP6_NF_IPTABLES
config option, but is not under it by itself.
gcc warns us about it :) :
net/netfilter/xt_hashlimit.c:473: warning: ‘hashlimit_ipv6_mask’ defined but
not used
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
---
diff --git
Andi Kleen wrote:
Works for me:
qdisc tbf 8001: root rate 1000bit burst 10b/8 mpu 0b lat 720.0ms
Sent 0 bytes 0 pkt (dropped 9, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
Packets are dropped as expected.
I can still reproduce it on 64bit with
Hi all, slowly crawling through the mails.
Brandeburg, Jesse wrote:
The test was done with various mtu sizes ranging from 1500 to 9000,
with ethernet flow control switched on and off, and using reno and
cubic as a TCP congestion control.
As asked in LKML thread, please post the exact netperf
Brief question I forgot to ask:
Right now we are using the old version 7.3.20-k2. To save some effort
on your end, shall we upgrade this to 7.6.15 or should our version be
good enough?
Thanks
Carsten
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message
Hi Bill,
I see similar results on my test systems
Thanks for this report and for confirming our observations. Could you
please confirm that a single-port bidrectional UDP link runs at wire
speed? This helps to localize the problem to the TCP stack or interaction
of the TCP stack with the
Hi David,
Could this be an issue with pause frames? At a previous job I remember
having issues with a similar configuration using two broadcom sb1250 3
gigE port devices. If I ran bidirectional tests on a single pair of
ports connected via cross over, it was slower than when I gave each
On Wed, 30 Jan 2008, Lennert Buytenhek wrote:
The RTL8150 driver uses an MTU of 1540 by default, which causes a
bunch of problems -- it prevents booting from NFS root, for one.
Agreed, although it is a bit strange how this particular bug has sneaked
up for so long...
cheers,
Petko
Em Thu, Jan 31, 2008 at 11:39:55AM -0200, Arnaldo Carvalho de Melo escreveu:
Em Thu, Jan 31, 2008 at 04:18:51PM +0300, Pavel Emelyanov escreveu:
Arnaldo Carvalho de Melo wrote:
Em Thu, Jan 31, 2008 at 03:32:09PM +0300, Pavel Emelyanov escreveu:
These two functions are the same except for
On Thu, Jan 31, 2008 at 05:42:34PM +0200, Petko Manolov wrote:
The RTL8150 driver uses an MTU of 1540 by default, which causes a
bunch of problems -- it prevents booting from NFS root, for one.
Agreed, although it is a bit strange how this particular bug has
sneaked up for so long...
I
Hi Andi,
Andi Kleen wrote:
Another issue with full duplex TCP not mentioned yet is that if TSO is used
the output will be somewhat bursty and might cause problems with the
TCP ACK clock of the other direction because the ACKs would need
to squeeze in between full TSO bursts.
You could try
Andi Kleen wrote:
I believe the problem was that all of my ports were used up with
TIME_WAIT sockets and so it couldn't create more. My test
case was similar to this:
Ah that's simple to solve then :- use more IP addresses and bind
to them in RR in your user program.
Arguably the
On Thu, Jan 31, 2008 at 08:41:38AM -0800, Ben Greear wrote:
I don't know exactly how the tcp_tw_recycle works, but it seems like it
could be made to only
take affect when all local ports are used up in TIME_WAIT.
TIME-WAIT does not actually use up local ports; it uses up remote ports
Hi all,
Brandeburg, Jesse wrote:
I would suggest you try TCP_RR with a command line something like
this: netperf -t TCP_RR -H hostname -C -c -- -b 4 -r 64K
I did that and the results can be found here:
https://n0.aei.uni-hannover.de/wiki/index.php/NetworkTest
seems something went wrong and
On Thu, 31 Jan 2008 13:46:32 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
TSO interacts badly with many queueing disciplines because they rely on
reordering packets from different streams and the large TSO packets can
make this difficult. This patch disables TSO for sockets that send over
Very sorry, re-posting as first patch was incomplete.
The below patch allows IPsec to use CTR mode with
AES encryption algorithm. Tested this using setkey
in ipsec-tools.
regards,
Joy
Signed-off-by: Joy Latten [EMAIL PROTECTED]
--
diff -urpN net-2.6.25/include/linux/pfkeyv2.h
Hi Bruce,
On Thu, 31 Jan 2008, Bruce Allen wrote:
I see similar results on my test systems
Thanks for this report and for confirming our observations. Could you
please confirm that a single-port bidrectional UDP link runs at wire
speed? This helps to localize the problem to the TCP
Carsten Aulbert wrote:
PS: Am I right that the TCP_RR tests should only be run on a single
node at a time, not on both ends simultaneously?
yes, they are a request/response test, and so perform the bidirectional
test with a single node starting the test.
--
To unsubscribe from this list: send
netperf was used without any special tuning parameters. Usually we start
two processes on two hosts which start (almost) simultaneously, last for
20-60 seconds and simply use UDP_STREAM (works well) and TCP_STREAM, i.e.
on 192.168.0.202: netperf -H 192.168.2.203 -t TCP_STREAL -l 20
on
Benjamin Thery wrote:
On Jan 31, 2008 3:58 PM, Daniel Lezcano [EMAIL PROTECTED] wrote:
Denis V. Lunev wrote:
Here are some preparations and cleanups to enable network device/inet
address notifiers inside a namespace.
This set of patches has been originally sent last Friday. One cleanup
patch
These patches add support for external classifiers to SFQ and add a
new flow classifier, which can do hashing based on user-specified
keys or deterministic mapping of keys to classes. Additionally there
is a patch to make the SFQ queues visisble as classes to verify that
the hash is indeed doing
[NET_SCHED]: Constify struct tcf_ext_map
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit 12e33ddf57910b685501df10bd92223ea9b98fd6
tree 1ce47c7b6b6b968940f3dc28f9d7839e78c85089
parent 8af03e782cae1e0a0f530ddd22301cdd12cf9dc0
author Patrick McHardy [EMAIL PROTECTED] Wed, 30 Jan 2008
[NET_SCHED]: sch_sfq: add support for external classifiers
Add support for external classifiers to allow using different flow hash
functions similar to ESFQ. When no classifier is attached the built-in
hash is used as before.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit
[NET_SCHED]: Add flow classifier
Add new flow classifier, which is meant to extend the SFQ hashing
capabilities without hard-coding new hash functions and also allows
deterministic mappings of keys to classes, replacing some out of tree
iptables patches like IPCLASSIFY (maps IPs to classes),
Fix the broken qdisc instead.
What do you mean? I don't think the qdiscs are broken.
I cannot think of any way how e.g. TBF can do anything useful
with large TSO packets.
-Andi
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More
[IPROUTE]: Add support for SFQ xstats
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit 196870f762ee393438c42115425f4af69e5b5186
tree 5650c1f93cc58886f8f97a0e55e374c157b96e2e
parent 54bb35c69cec6c730a4ac95530a1d2ca6670f73b
author Patrick McHardy [EMAIL PROTECTED] Thu, 31 Jan 2008
[IPROUTE]: Add flow classifier support
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit ac3df2d7e37826b06cc9093f50d829a9da1873a4
tree b33a2b29abdcea0267fe7a357d282a4c2f67124b
parent 196870f762ee393438c42115425f4af69e5b5186
author Patrick McHardy [EMAIL PROTECTED] Thu, 31 Jan 2008
Andi Kleen wrote:
Fix the broken qdisc instead.
What do you mean? I don't think the qdiscs are broken.
I cannot think of any way how e.g. TBF can do anything useful
with large TSO packets.
Someone posted a patch some time ago to calculate the amount
of tokens needed in max_size portions and
On 01/29/2008 12:18 PM, Patrick McHardy wrote:
Chuck Ebbert wrote:
nf_nat_move_storage():
/usr/src/debug/kernel-2.6.23/linux-2.6.23.i686/net/ipv4/netfilter/nf_nat_core.c:612
87: f7 47 64 80 01 00 00testl $0x180,0x64(%edi)
8e: 74 39 je c9
Carsten Aulbert wrote:
Hi Andi,
Andi Kleen wrote:
Another issue with full duplex TCP not mentioned yet is that if TSO is
used the output will be somewhat bursty and might cause problems with
the TCP ACK clock of the other direction because the ACKs would need
to squeeze in between full
Then change TBF to use skb_gso_segment? Be careful, the fact that
That doesn't help because it wants to interleave packets
from different streams to get everything fair and smooth. The only
good way to handle that is to split it up and the simplest way to do
this is to just tell TCP to not do
Andi Kleen wrote:
Then change TBF to use skb_gso_segment? Be careful, the fact that
That doesn't help because it wants to interleave packets
from different streams to get everything fair and smooth. The only
good way to handle that is to split it up and the simplest way to do
this is to
Andi Kleen wrote:
TSO interacts badly with many queueing disciplines because they rely on
reordering packets from different streams and the large TSO packets can
make this difficult. This patch disables TSO for sockets that send over
devices with non standard queueing disciplines. That's
Stephen Hemminger wrote:
On Thu, 31 Jan 2008 19:37:35 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
On Thu, Jan 31, 2008 at 07:01:00PM +0100, Patrick McHardy wrote:
Andi Kleen wrote:
Fix the broken qdisc instead.
What do you mean? I don't think the qdiscs are broken.
I cannot think of any way
Carsten Aulbert wrote:
Hi all, slowly crawling through the mails.
Brandeburg, Jesse wrote:
The test was done with various mtu sizes ranging from 1500 to 9000,
with ethernet flow control switched on and off, and using reno and
cubic as a TCP congestion control.
As asked in LKML thread,
On Thu, Jan 31, 2008 at 07:21:20PM +0100, Patrick McHardy wrote:
Andi Kleen wrote:
Then change TBF to use skb_gso_segment? Be careful, the fact that
That doesn't help because it wants to interleave packets
from different streams to get everything fair and smooth. The only
good way to
Bill Fink wrote:
a 2.6.15.4 kernel. The GigE NICs are Intel PRO/1000
82546EB_QUAD_COPPER,
on a 64-bit/133-MHz PCI-X bus, using version 6.1.16-k2 of the e1000
driver, and running with 9000-byte jumbo frames. The TCP congestion
control is BIC.
Bill, FYI, there was a known issue with e1000
On Thu, Jan 31, 2008 at 10:26:19AM -0800, Rick Jones wrote:
Andi Kleen wrote:
TSO interacts badly with many queueing disciplines because they rely on
reordering packets from different streams and the large TSO packets can
make this difficult. This patch disables TSO for sockets that send
1 - 100 of 191 matches
Mail list logo
