From: John W. Linville [EMAIL PROTECTED]
Date: Sat, 22 Sep 2007 15:54:57 -0400
Another round of miscellaneous driver and stack fixes intended for
2.6.24...
The tree is based on the latest net-2.6.24 as of this morning.
I've included a 'master-davem' branch in my tree as a reference in
case
Roland Dreier wrote:
+ ipoib_slave_detach(cpriv-dev);
unregister_netdev(cpriv-dev);
Maybe you already answered this before, but I'm still not clear why
this notifier call can't just be added to the start of
unregister_netdevice(), so we can avoid having driver
On Sun, 2007-23-09 at 12:45 +0800, john ye wrote:
I do randomly select a CPU to dispatch the skb to. Previously, I
dispatch
skb evenly to all CPUs( round robin, one by one). but I didn't find a
quick
coding. for_each_online_cpu is not quick enough.
for_each_online_cpu doenst look that
Dear Jamal,
Yes. you are right. I do need some real fast traffic generator; possibly
one that can do
thousands of tcp sessions. to get some kind of convincing result.
Also, the packet reordering is also my big concern. round-robin doesn't have
much help.
The INPUT speed is doubled by using 2
The action in bonding to a detach of slave is to unregister the master (see
patch 10).
This can't be done from the context of unregister_netdevice itself (it is
protected by rtnl_lock).
I'm confused. Your patch has:
+ipoib_slave_detach(cpriv-dev);
I had plenty of time this weekend so i have been doing a _lot_ of
testing. My next emails will send a set of patches:
Patch 1: Introduces explicit tx locking
Patch 2: Introduces batching interface
Patch 3: Core uses batching interface
Patch 4: get rid of dev-gso_skb
Testing
---
Each of
Evgeniy Polyakov wrote:
Hi Steve.
On Sun, Sep 23, 2007 at 11:12:12AM -0500, Steve Wise ([EMAIL PROTECTED]) wrote:
The pktgen module provides a way to clone the skb its using for
transmission, and allows passing N clones of the originally created skb
to the driver under test.However, it
I have submitted this before; but here it is again.
Against net-2.6.24 from yesterday for this and all following patches.
cheers,
jamal
[NET_SCHED] explict hold dev tx lock
For N cpus, with full throttle traffic on all N CPUs, funneling traffic
to the same ethernet device, the devices queue
This patch introduces the netdevice interface for batching.
cheers,
jamal
[NET_BATCH] Introduce batching interface
This patch introduces the netdevice interface for batching.
A typical driver dev-hard_start_xmit() has 4 parts:
a) packet formating (example vlan, mss, descriptor counting etc)
This patch adds the usage of batching within the core.
cheers,
jamal
[NET_BATCH] net core use batching
This patch adds the usage of batching within the core.
The same test methodology used in introducing txlock is used, with
the following results on different kernels:
This patch removes dev-gso_skb as it is no longer necessary with
batching code.
cheers,
jamal
[NET_SCHED] kill dev-gso_skb
The batching code does what gso used to batch at the drivers.
There is no more need for gso_skb. If for whatever reason the
requeueing is a bad idea we are going to leave
Hi Steve.
On Sun, Sep 23, 2007 at 11:12:12AM -0500, Steve Wise ([EMAIL PROTECTED]) wrote:
The pktgen module provides a way to clone the skb its using for
transmission, and allows passing N clones of the originally created skb
to the driver under test.However, it doesn't really use
John,
It will NEVER be an acceptable solution as long as you have re-ordering.
I will look at it - but i have to run out for now. In the meantime,
I have indented it for you to be in proper kernel format so others can
also look it. Attached.
cheers,
jamal
/*
* BOTTOM_SOFTIRQ_NET
* An
On Sun, 2007-23-09 at 12:55 -0500, Steve Wise wrote:
Its a hack that breaks cxgb3 because cxgb3 uses the skb-cb area for
each skb passed down. So cxgb3 is at fault then? IE a driver cannot
use the skb-cb field if the users count is 1? Or maybe a driver can
_never_ use the cb field?
jamal wrote:
More patches to follow - i didnt want to overload people by dumping
too many patches. Most of these patches below are ready to go; some are
need some testing and others need a little porting from an earlier
kernel:
- tg3 driver (tested and works well, but dont want to send
- tun
On Sun, 2007-23-09 at 14:19 -0400, Jeff Garzik wrote:
You should post at least a couple driver patches to see how its used on
Real Hardware(tm)... :)
This is the tg3 patch i used for the testing - against whats in Daves
net-2.6.24 tree. Patch may be a bit hard to read.
For an example of
Sean Hefty wrote:
The iWARP driver must translate all listens on address 0.0.0.0 to the
set of rdma-only ip addresses for the device in question. This prevents
incoming connect requests to the TCP ipaddresses from going up the
rdma stack.
I've only given this a high level review at this
iw_cxgb3: Support iwarp-only interfaces to avoid 4-tuple conflicts.
Version 3:
- don't use list_del_init() where list_del() is sufficient.
Version 2:
- added a per-device mutex for the address and listening endpoints lists.
- wait for all replies if sending multiple passive_open requests to
jamal wrote:
On Sun, 2007-23-09 at 14:19 -0400, Jeff Garzik wrote:
You should post at least a couple driver patches to see how its used on
Real Hardware(tm)... :)
This is the tg3 patch i used for the testing - against whats in Daves
net-2.6.24 tree. Patch may be a bit hard to read.
On Sat, Sep 22, 2007 at 10:58:18PM -0700, David Miller wrote:
From: Ulrich Drepper [EMAIL PROTECTED]
Date: Sat, 22 Sep 2007 10:11:01 -0700
There was no public mail. I asked RH engineering for proposals for
changes to the POSIX spec and Alan replied.
Please do not discuss such proposals
On Sun, 23 Sep 2007, Herbert Xu wrote:
Krzysztof Oledzki [EMAIL PROTECTED] wrote:
It seems that after some not very recent changes udp and tcp packes
carring data send by a loopback have incorrect cksum:
This correct. The loopback interfaces has the no checksum flag
set so we only
On Sun, 2007-23-09 at 12:36 -0700, Kok, Auke wrote:
please be reminded that we're going to strip down e1000 and most of the
features
should go into e1000e, which has much less hardware workarounds. I'm still
reluctant to putting in new stuff in e1000 - I really want to chop it down
first
On Sun, Sep 23, 2007 at 11:18:58PM +0200, Krzysztof Oledzki wrote:
Thank you for the information. Is there any easy way to turn them on? I
need it for LVS.
Do you really need it? The packets should be checksummed at
the point where they physically leave the host.
Cheers,
--
Visit Openswan
Dear Jamal,
Thanks, bothered you all.
I will look into the 2 issues. re-ordering and spinlock, and do extensive
test.
Once having result, no matter positive or negative, I will contact you.
The format will not be a mess any more.
John Ye
- Original Message -
From: jamal [EMAIL
24 matches
Mail list logo
