* [ofa-general] Re: [PATCH V6 0/9] net/bonding: ADD IPoIB support for the bonding driver
From: Roland Dreier @ 2007-09-25 15:39 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Jeff Garzik, OpenFabrics General, netdev
In-Reply-To: <10376.1190733869@death>
> Roland, are you comfortable with the IB changes in patches 1 and 2?
Yes, they look fine to me. Feel free to apply, with
Acked-by: Roland Dreier <rolandd@cisco.com>
- R.
^ permalink raw reply
* Re: [PATCH: 2.6.13-15-SMP 3/3] network: concurrently runsoftirqnetwork code on SMP
From: Stephen Hemminger @ 2007-09-25 16:03 UTC (permalink / raw)
To: john ye
Cc: hadi, David Miller, netdev, kuznet, pekkas, jmorris, kaber,
iceburgue, John Ye
In-Reply-To: <007201c7ff89$d5db4cf0$d6ddfea9@JOHNYE1>
On Tue, 25 Sep 2007 23:36:25 +0800
"john ye" <johny@asimco.com.cn> wrote:
> Jamal,
>
> You pointed out a key point: it's NOT acceptable if massive packet re-ordering couldn¡¯t be avoided.
> I debugged function tcp_ofo_queue in net/ipv4/tcp_input.c & monitored out_of_order_queue, found that re-ordering
> becomes unacceptable with the softirq load grows.
>
> It's simple to avoid out-of-order packets by changing random dispatch into dispatch based on source ip address.
> e.g. cpu = iph->saddr % nr_cpus. while cpu is like a hash entry.
> Considering that BS patch is mainly used on server with many incoming connections,
> dispatch by IP should balance CPU load well.
>
> The test is under way, it's not bad so far.
> The queue spin_lock seems not cost much.
>
> Below is the bcpp beautified module code. Last time code mess is caused by outlook express which killed tabs.
>
> Thanks.
>
> John Ye
There is a standard hash called RSS, that many drivers support because it is
used by other operating systems.
^ permalink raw reply
* Re: [PATCH] Remove broken netfilter binary sysctls from bridging code
From: Stephen Hemminger @ 2007-09-25 16:12 UTC (permalink / raw)
To: Patrick McHardy; +Cc: linux-kernel, Linux Netdev List
In-Reply-To: <46F8897C.5010504@trash.net>
On Tue, 25 Sep 2007 06:07:24 +0200
Patrick McHardy <kaber@trash.net> wrote:
> Stephen Hemminger wrote:
> > On Mon, 24 Sep 2007 18:55:38 +0200
> > Patrick McHardy <kaber@trash.net> wrote:
> >
> >>Eric W. Biederman wrote:
> >>
> >>>A really good fix would be to remove the binary side and then to
> >>>modify brnf_sysctl_call_tables to allocate a temporary ctl_table
> >>>and integer on the stack and only set ctl->data after we have
> >>>normalized the written value. But since in practice nothing cares
> >>>about the race a better fix probably isn't worth it.
> >>
> >>
> >>I seem to be missing something, the entire brnf_sysctl_call_tables
> >>thing looks purely cosmetic to me, wouldn't it be better to simply
> >>remove it?
> >
> >
> > I agree, removing seems like a better option. But probably need to
> > go through a 3-6mo warning period, since sysctl's are technically
> > an API.
>
>
> I meant removing brnf_sysctl_call_tables function, not the sysctls
> themselves, all it does is change values != 0 to 1. Or did you
> actually mean that something in userspace might depend on reading
> back the value 1 after writing a value != 0?
I was going farther, because don't really see the value of having
a sysctl for this. It seems better to just not load filters if
they aren't going to be used. Having another enable/disable hook
just adds needless complexity.
^ permalink raw reply
* Re: 2.6.23-rc8-mm1 - drivers/net/ibm_newemac/mal - broken
From: Andrew Morton @ 2007-09-25 16:16 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linux-kernel, eugene.surovegin, netdev
In-Reply-To: <46F904E6.40601@linux.vnet.ibm.com>
On Tue, 25 Sep 2007 18:23:58 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Hi Andrew,
>
> The drivers/net/ibm_newemac/mal seems to be broken, which stop with
> build error
(please cc netdev@vger.kernel.org on networking things)
> CC drivers/net/ibm_newemac/mal.o
> drivers/net/ibm_newemac/mal.c: In function ‘mal_schedule_poll’:
> drivers/net/ibm_newemac/mal.c:238: error: too few arguments to function ‘netif_rx_schedule_prep’
> drivers/net/ibm_newemac/mal.c:238: error: too few arguments to function ‘netif_rx_schedule_prep’
> drivers/net/ibm_newemac/mal.c:238: error: too few arguments to function ‘netif_rx_schedule_prep’
> drivers/net/ibm_newemac/mal.c:241: error: too few arguments to function ‘__netif_rx_schedule’
> drivers/net/ibm_newemac/mal.c: In function ‘mal_poll_disable’:
> drivers/net/ibm_newemac/mal.c:321: error: ‘__LINK_STATE_RX_SCHED’ undeclared (first use in this function)
> drivers/net/ibm_newemac/mal.c:321: error: (Each undeclared identifier is reported only once
> drivers/net/ibm_newemac/mal.c:321: error: for each function it appears in.)
> drivers/net/ibm_newemac/mal.c: In function ‘mal_poll’:
> drivers/net/ibm_newemac/mal.c:337: error: ‘struct net_device’ has no member named ‘quota’
> drivers/net/ibm_newemac/mal.c:337: warning: type defaults to ‘int’ in declaration of ‘_x’
> drivers/net/ibm_newemac/mal.c:337: error: ‘struct net_device’ has no member named ‘quota’
> drivers/net/ibm_newemac/mal.c:375: error: too few arguments to function ‘__netif_rx_complete’
> drivers/net/ibm_newemac/mal.c:390: warning: passing argument 2 of ‘netif_rx_reschedule’ makes pointer from integer without a cast
> drivers/net/ibm_newemac/mal.c:404: error: ‘struct net_device’ has no member named ‘quota’
> drivers/net/ibm_newemac/mal.c: In function ‘mal_probe’:
> drivers/net/ibm_newemac/mal.c:542: error: ‘struct net_device’ has no member named ‘weight’
> drivers/net/ibm_newemac/mal.c:543: error: ‘struct net_device’ has no member named ‘poll’
> drivers/net/ibm_newemac/mal.c: In function ‘mal_remove’:
> drivers/net/ibm_newemac/mal.c:660: error: implicit declaration of function ‘netif_poll_disable’
> make[3]: *** [drivers/net/ibm_newemac/mal.o] Error 1
> make[2]: *** [drivers/net/ibm_newemac] Error 2
> make[1]: *** [drivers/net] Error 2
> make: *** [drivers] Error 2
Yes, there's been a lot of breakage in netdev land:
git-net-fix-macec.patch
git-net-sky2-fixups.patch
git-net-fix-wireless-kconfig.patch
git-net-fix-spidernet-build.patch
git-net-sctp-build-fix.patch
spider_net_ethtool-keep-up-with-recent-netdev-stats-changes.patch
pasemi_mac-build-fix-after-recent-netdev-stats.patch
git-net-fix-pasemi_mac.patch
make-mv643xx_ethc-build-again.patch
but we're getting there. It looks like ibmn_newemac is more busted than
most...
^ permalink raw reply
* Re: [PATCH] sb1250-mac: Driver model & phylib update
From: Andrew Morton @ 2007-09-25 16:18 UTC (permalink / raw)
To: Ralf Baechle
Cc: Maciej W. Rozycki, Jeff Garzik, netdev, linux-mips, linux-kernel
In-Reply-To: <20070925131817.GA28402@linux-mips.org>
On Tue, 25 Sep 2007 14:18:17 +0100 Ralf Baechle <ralf@linux-mips.org> wrote:
> On Fri, Sep 21, 2007 at 12:44:09PM -0700, Andrew Morton wrote:
>
> > > A driver model and phylib update.
> >
> > akpm:/usr/src/25> diffstat patches/git-net.patch | tail -n 1
> > 1013 files changed, 187667 insertions(+), 23587 deletions(-)
> >
> > Sorry, but raising networking patches against Linus's crufty
> > old mainline tree just isn't viable at present.
>
> Out of curiosity:
>
> [ralf@denk linux-queue]$ git diff $(git merge-base master v2.6.23-rc8-mm1)..v2.6.23-rc8-mm1 | wc -cl
> 1046669 31900996
> [ralf@denk linux-queue]$ git diff $(git merge-base master v2.6.23-rc8-mm1)..v2.6.23-rc8-mm1 | diffstat | tail -1
> 6049 files changed, 573635 insertions(+), 207630 deletions(-)
A few years ago I thought it might slow down soon.
> [ralf@denk linux-queue]$
>
> We're all a little too productive ;-)
s/prod/destr/
^ permalink raw reply
* Re: [PATCH] Remove broken netfilter binary sysctls from bridging code
From: Patrick McHardy @ 2007-09-25 16:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: linux-kernel, Linux Netdev List
In-Reply-To: <20070925091203.371879e2@fujitsu-loaner>
Stephen Hemminger wrote:
> On Tue, 25 Sep 2007 06:07:24 +0200
> Patrick McHardy <kaber@trash.net> wrote:
>
>
>> I meant removing brnf_sysctl_call_tables function, not the sysctls
>> themselves, all it does is change values != 0 to 1. Or did you
>> actually mean that something in userspace might depend on reading
>> back the value 1 after writing a value != 0?
>>
>
> I was going farther, because don't really see the value of having
> a sysctl for this. It seems better to just not load filters if
> they aren't going to be used. Having another enable/disable hook
> just adds needless complexity.
>
These sysctls control whether bridged packets will be handled
by iptables and friends. The bridge netfilter code always
handles bridged packets, and iptables might be loaded for
different reasons. So I don't see how that would work.
I think it should be specified in the ebtables ruleset, but
the current netfilter infrastructure doesn't allow to do that
cleanly.
^ permalink raw reply
* Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
From: Oliver Hartkopp @ 2007-09-25 17:55 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / È£ÑÀ
Cc: Patrick McHardy, Urs Thuermann, netdev, davem, joe, tglx,
oliver.hartkopp
In-Reply-To: <46F91F64.2050008@trash.net>
Patrick McHardy wrote:
> Urs Thuermann wrote:
>
>> YOSHIFUJI Hideaki / È£ÑÀ <yoshfuji@linux-ipv6.org> writes:
>>
>>
>>
>>> I'm not a lawyer, but the following lines:
>>>
>>> | + * Alternatively, provided that this notice is retained in full, this
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> | + * software may be distributed under the terms of the GNU General
>>> | + * Public License ("GPL") version 2 as distributed in the 'COPYING'
>>> | + * file from the main directory of the linux kernel source.
>>>
>>> make this whole licence imcompatible with GPL.
>>>
>>
The module license is "Dual BSD/GPL" as many other code in the Linux
Kernel. So this should not be any problem.
>>> I do think you need to allow people to select GPLv2 only.
>>>
>>
The Linux Kernel is currently under GPLv2 and we just wanted to follow
Linus' mind and so we referenced the COPYING file which many other
source does as well. Indeed it was a hard thing to make our code
available under GPL (as creating and publishing open source software is
really no a usual thing for the Volkswagen rights department). So i
discussed with the rights department about several disclaimers inside
the current Kernel (especially the stuff that has been signed off by
companies like IBM, Motorola, etc.). In this process it turned out to be
the best to license the code under "Dual BSD/GPL" as it grants more
rights to the programmer (including ourselves) than a GPL only license.
I assume this was the intention from IBM, Motorola and all the others
also. Btw. inside the Kernel context it behaves exactly like GPL code
(like all the other dual license code).
So i really can't see any problem here. If so there would have been a
big discussion about the other "Dual BSD/GPL" code.
Best regards,
Oliver
ps. I hope, i found the right words right now, as i'm not very familiar
with English :)
^ permalink raw reply
* Userspace network stack and netchannels.
From: Evgeniy Polyakov @ 2007-09-25 18:00 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1608 bytes --]
Hi.
I've released new version of the extremely small
userspace netowork stack [1] implementation.
Stack supports TCP and UDP over IP.
It works on top of netchannels [2] or packet socket
(returned back in this release).
Supported features:
* TCP/UDP sending and receiving.
* Timestamp, window scaling, MSS TCP options.
* PAWS.
* Slow start and congestion control.
* Socket-like interface.
* Retransmit and fast retransmit support.
* support for TCP listen state (only point-to-point mode,
i.e. no new data channels are created, when new client is
connected, instead state is changed according to protocol
(TCP state is changed to ESTABLISHED).
* support for the netchannels and packet socket interface.
It was proven [3] that unetstack can be *much* faster than vanilla TCP
stack (mainly because of heavily reduced number of syscalls, different
congestion control algorithm and other features).
This release includes number of bugs fixed (thanks to Salvatore Del
Popolo for continuously kicking me), packet socket interface (enabled at
compile time) and small documentation update (including example).
Attached archive for intrested readers.
Thank you.
1. Userspace network stack.
http://tservice.net.ru/~s0mbre/old/?section=projects&item=unetstack
2. Netchannel subsystem.
http://tservice.net.ru/~s0mbre/old/?section=projects&item=netchannel
3. Gigabit send/recv benchmark for netchannels and sockets using small
packets.
http://tservice.net.ru/~s0mbre/blog/devel/networking/2006_10_26.html
http://tservice.net.ru/~s0mbre/blog/devel/networking/2006_12_21.html
--
Evgeniy Polyakov
[-- Attachment #2: unetstack-2007_09_25.tar.gz --]
[-- Type: application/x-tar-gz, Size: 25717 bytes --]
^ permalink raw reply
* Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
From: Patrick McHardy @ 2007-09-25 17:53 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: YOSHIFUJI Hideaki / È£ÑÀ, Urs Thuermann,
netdev, davem, joe, tglx, oliver.hartkopp
In-Reply-To: <46F94B91.5020209@hartkopp.net>
Oliver Hartkopp wrote:
>>>>I do think you need to allow people to select GPLv2 only.
>>>>
>>>
> The Linux Kernel is currently under GPLv2 and we just wanted to follow
> Linus' mind and so we referenced the COPYING file which many other
> source does as well. Indeed it was a hard thing to make our code
> available under GPL (as creating and publishing open source software is
> really no a usual thing for the Volkswagen rights department). So i
> discussed with the rights department about several disclaimers inside
> the current Kernel (especially the stuff that has been signed off by
> companies like IBM, Motorola, etc.). In this process it turned out to be
> the best to license the code under "Dual BSD/GPL" as it grants more
> rights to the programmer (including ourselves) than a GPL only license.
> I assume this was the intention from IBM, Motorola and all the others
> also. Btw. inside the Kernel context it behaves exactly like GPL code
> (like all the other dual license code).
>
> So i really can't see any problem here. If so there would have been a
> big discussion about the other "Dual BSD/GPL" code.
Yoshifuji's point was that the license seems to contradict itself,
it says you may choose GPL, but have to retain BSD. And that is
not about Dual BSD/GPL but about the specific wording.
/me runs and refrains from the discussion as promised :)
^ permalink raw reply
* Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
From: Oliver Hartkopp @ 2007-09-25 19:09 UTC (permalink / raw)
To: Patrick McHardy, YOSHIFUJI Hideaki / È£ÑÀ
Cc: Urs Thuermann, netdev, davem, joe, tglx, oliver.hartkopp
In-Reply-To: <46F94B00.3060006@trash.net>
Patrick McHardy wrote:
>
> Yoshifuji's point was that the license seems to contradict itself,
> it says you may choose GPL, but have to retain BSD. And that is
> not about Dual BSD/GPL but about the specific wording.
>
Got it (finally)!
Trying to specify the GPL Version (and the reference to the COPYING
file) i just overlooked the second part
"*/*/in which case the provisions of the GPL apply INSTEAD OF those
given above."/*/* of the original sentence.
Sorry. Was no* malice aforethought :)*
Of course we'll fix this to have the same wording like e.g. in
arch/i386/crypto/aes.c .
Thanks to Yoshfuji for catching this and to Patrick for making it clear
to me!*
Best regards,
Oliver
*
^ permalink raw reply
* Re: Userspace network stack and netchannels.
From: Robert Iakobashvili @ 2007-09-25 19:22 UTC (permalink / raw)
To: netdev
In-Reply-To: <7e63f56c0709251220s12ab10b5pade5b2c90fa4a8b9@mail.gmail.com>
Evgeniy,
On 9/25/07, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> I've released new version of the extremely small
> userspace netowork stack [1] implementation.
>
> 1. Userspace network stack.
> http://tservice.net.ru/~s0mbre/old/?section=projects&item=unetstack
>
> 2. Netchannel subsystem.
> http://tservice.net.ru/~s0mbre/old/?section=projects&item=netchannel
>
> 3. Gigabit send/recv benchmark for netchannels and sockets using small
> packets.
> http://tservice.net.ru/~s0mbre/blog/devel/networking/2006_10_26.html
> http://tservice.net.ru/~s0mbre/blog/devel/networking/2006_12_21.html
>
Very interesting. Are there any details of your benchmarking available,
namely, how it was done?
Have you some comparison profiling data (oprofile) to figure out where
the advantages are coming from?
--
Sincerely,
Robert Iakobashvili,
coroberti %x40 gmail %x2e com
...........................................................
http://curl-loader.sourceforge.net
A web testing and traffic generation tool.
--
Sincerely,
Robert Iakobashvili,
coroberti %x40 gmail %x2e com
...........................................................
http://curl-loader.sourceforge.net
A web testing and traffic generation tool.
^ permalink raw reply
* Re: Userspace network stack and netchannels.
From: Stephen Hemminger @ 2007-09-25 19:34 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: netdev
In-Reply-To: <20070925180043.GA16698@2ka.mipt.ru>
On Tue, 25 Sep 2007 22:00:48 +0400
Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> Hi.
>
> I've released new version of the extremely small
> userspace netowork stack [1] implementation.
> Stack supports TCP and UDP over IP.
> It works on top of netchannels [2] or packet socket
> (returned back in this release).
>
> Supported features:
> * TCP/UDP sending and receiving.
> * Timestamp, window scaling, MSS TCP options.
> * PAWS.
> * Slow start and congestion control.
> * Socket-like interface.
> * Retransmit and fast retransmit support.
> * support for TCP listen state (only point-to-point mode,
> i.e. no new data channels are created, when new client is
> connected, instead state is changed according to protocol
> (TCP state is changed to ESTABLISHED).
> * support for the netchannels and packet socket interface.
>
> It was proven [3] that unetstack can be *much* faster than vanilla TCP
> stack (mainly because of heavily reduced number of syscalls, different
> congestion control algorithm and other features).
I am glad to see a more complete implementation for comparison, but
by changing several variables at once it makes it hard to evaluate whether
the improvement comes from user space TCP or the other changes.
^ permalink raw reply
* [git patches] additional net driver fixes
From: Jeff Garzik @ 2007-09-25 19:51 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: netdev, LKML
These two wireless fixes are IN ADDITION to the previously submitted
fixes. Same linear history. In other words, if you pull
"upstream-linus", you will get both the changes below, _and_ the changes
I submitted yesterday. If you have already pulled yesterday's fixes,
then you will only receive the changesets below.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus
to receive the following updates:
fs/compat_ioctl.c | 2 +
net/ieee80211/softmac/ieee80211softmac_assoc.c | 2 -
net/ieee80211/softmac/ieee80211softmac_wx.c | 54 +++++++++---------------
7 files changed, 61 insertions(+), 52 deletions(-)
Jean Tourrilhes (1):
WE : Add missing auth compat-ioctl
Larry Finger (1):
softmac: Fix inability to associate with WEP networks
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index 5a5b711..37310b0 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -3190,6 +3190,8 @@ COMPATIBLE_IOCTL(SIOCSIWRETRY)
COMPATIBLE_IOCTL(SIOCGIWRETRY)
COMPATIBLE_IOCTL(SIOCSIWPOWER)
COMPATIBLE_IOCTL(SIOCGIWPOWER)
+COMPATIBLE_IOCTL(SIOCSIWAUTH)
+COMPATIBLE_IOCTL(SIOCGIWAUTH)
/* hiddev */
COMPATIBLE_IOCTL(HIDIOCGVERSION)
COMPATIBLE_IOCTL(HIDIOCAPPLICATION)
diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index afb6c66..e475f2e 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -273,8 +273,6 @@ ieee80211softmac_assoc_work(struct work_struct *work)
ieee80211softmac_notify(mac->dev, IEEE80211SOFTMAC_EVENT_SCAN_FINISHED, ieee80211softmac_assoc_notify_scan, NULL);
if (ieee80211softmac_start_scan(mac)) {
dprintk(KERN_INFO PFX "Associate: failed to initiate scan. Is device up?\n");
- mac->associnfo.associating = 0;
- mac->associnfo.associated = 0;
}
goto out;
} else {
diff --git a/net/ieee80211/softmac/ieee80211softmac_wx.c b/net/ieee80211/softmac/ieee80211softmac_wx.c
index d054e92..442b987 100644
--- a/net/ieee80211/softmac/ieee80211softmac_wx.c
+++ b/net/ieee80211/softmac/ieee80211softmac_wx.c
@@ -70,44 +70,30 @@ ieee80211softmac_wx_set_essid(struct net_device *net_dev,
char *extra)
{
struct ieee80211softmac_device *sm = ieee80211_priv(net_dev);
- struct ieee80211softmac_network *n;
struct ieee80211softmac_auth_queue_item *authptr;
int length = 0;
check_assoc_again:
mutex_lock(&sm->associnfo.mutex);
- /* Check if we're already associating to this or another network
- * If it's another network, cancel and start over with our new network
- * If it's our network, ignore the change, we're already doing it!
- */
if((sm->associnfo.associating || sm->associnfo.associated) &&
(data->essid.flags && data->essid.length)) {
- /* Get the associating network */
- n = ieee80211softmac_get_network_by_bssid(sm, sm->associnfo.bssid);
- if(n && n->essid.len == data->essid.length &&
- !memcmp(n->essid.data, extra, n->essid.len)) {
- dprintk(KERN_INFO PFX "Already associating or associated to "MAC_FMT"\n",
- MAC_ARG(sm->associnfo.bssid));
- goto out;
- } else {
- dprintk(KERN_INFO PFX "Canceling existing associate request!\n");
- /* Cancel assoc work */
- cancel_delayed_work(&sm->associnfo.work);
- /* We don't have to do this, but it's a little cleaner */
- list_for_each_entry(authptr, &sm->auth_queue, list)
- cancel_delayed_work(&authptr->work);
- sm->associnfo.bssvalid = 0;
- sm->associnfo.bssfixed = 0;
- sm->associnfo.associating = 0;
- sm->associnfo.associated = 0;
- /* We must unlock to avoid deadlocks with the assoc workqueue
- * on the associnfo.mutex */
- mutex_unlock(&sm->associnfo.mutex);
- flush_scheduled_work();
- /* Avoid race! Check assoc status again. Maybe someone started an
- * association while we flushed. */
- goto check_assoc_again;
- }
+ dprintk(KERN_INFO PFX "Canceling existing associate request!\n");
+ /* Cancel assoc work */
+ cancel_delayed_work(&sm->associnfo.work);
+ /* We don't have to do this, but it's a little cleaner */
+ list_for_each_entry(authptr, &sm->auth_queue, list)
+ cancel_delayed_work(&authptr->work);
+ sm->associnfo.bssvalid = 0;
+ sm->associnfo.bssfixed = 0;
+ sm->associnfo.associating = 0;
+ sm->associnfo.associated = 0;
+ /* We must unlock to avoid deadlocks with the assoc workqueue
+ * on the associnfo.mutex */
+ mutex_unlock(&sm->associnfo.mutex);
+ flush_scheduled_work();
+ /* Avoid race! Check assoc status again. Maybe someone started an
+ * association while we flushed. */
+ goto check_assoc_again;
}
sm->associnfo.static_essid = 0;
@@ -153,13 +139,13 @@ ieee80211softmac_wx_get_essid(struct net_device *net_dev,
data->essid.length = sm->associnfo.req_essid.len;
data->essid.flags = 1; /* active */
memcpy(extra, sm->associnfo.req_essid.data, sm->associnfo.req_essid.len);
- }
-
+ dprintk(KERN_INFO PFX "Getting essid from req_essid\n");
+ } else if (sm->associnfo.associated || sm->associnfo.associating) {
/* If we're associating/associated, return that */
- if (sm->associnfo.associated || sm->associnfo.associating) {
data->essid.length = sm->associnfo.associate_essid.len;
data->essid.flags = 1; /* active */
memcpy(extra, sm->associnfo.associate_essid.data, sm->associnfo.associate_essid.len);
+ dprintk(KERN_INFO PFX "Getting essid from associate_essid\n");
}
mutex_unlock(&sm->associnfo.mutex);
^ permalink raw reply related
* [ofa-general] Re: [DOC] Net batching driver howto
From: Randy Dunlap @ 2007-09-25 20:16 UTC (permalink / raw)
To: hadi
Cc: johnpol, peter.p.waskiewicz.jr, kumarkr, herbert, Jeff Garzik,
Robert.Olsson, netdev, rdreier, mcarlson, David Miller, gaagaan,
jagana, general, mchan, tgraf, sri, shemminger, kaber
In-Reply-To: <1190674459.4264.28.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 536 bytes --]
On Mon, 24 Sep 2007 18:54:19 -0400 jamal wrote:
> I have updated the driver howto to match the patches i posted yesterday.
> attached.
Thanks for sending this.
This is an early draft, right?
I'll fix some typos etc. in it (patch attached) and add some whitespace.
Please see RD: in the patch for more questions/comments.
IMO it needs some changes to eliminate words like "we", "you",
and "your" (words that personify code). Those words are OK
when talking about yourself.
---
~Randy
Phaedrus says that Quality is about caring.
[-- Attachment #2: batch-howto.patch --]
[-- Type: text/x-patch, Size: 11579 bytes --]
batch-driver-howto.txt | 116 +++++++++++++++++++++------------------
1 file changed, 63 insertions(+), 53 deletions(-)
diff -Naurp tmp/batch-driver-howto.txt~fix1 tmp/batch-driver-howto.txt
--- tmp/batch-driver-howto.txt~fix1 2007-09-25 12:44:10.000000000 -0700
+++ tmp/batch-driver-howto.txt 2007-09-25 13:14:27.000000000 -0700
@@ -1,13 +1,13 @@
-Heres the begining of a howto for driver authors.
+Here's the beginning of a howto for driver authors.
The intended audience for this howto is people already
familiar with netdevices.
-1.0 Netdevice Pre-requisites
+1.0 Netdevice Prerequisites
------------------------------
-For hardware based netdevices, you must have at least hardware that
-is capable of doing DMA with many descriptors; i.e having hardware
+For hardware-based netdevices, you must have at least hardware that
+is capable of doing DMA with many descriptors; i.e., having hardware
with a queue length of 3 (as in some fscked ethernet hardware) is
not very useful in this case.
@@ -15,33 +15,36 @@ not very useful in this case.
-----------------------------------
There are 3 new methods and one new variable introduced. These are:
-1)dev->hard_prep_xmit()
-2)dev->hard_end_xmit()
-3)dev->hard_batch_xmit()
-4)dev->xmit_win
+1) dev->hard_prep_xmit()
+2) dev->hard_end_xmit()
+3) dev->hard_batch_xmit()
+4) dev->xmit_win
2.1 Using Core driver changes
-----------------------------
-To provide context, lets look at a typical driver abstraction
+To provide context, let's look at a typical driver abstraction
for dev->hard_start_xmit(). It has 4 parts:
-a) packet formating (example vlan, mss, descriptor counting etc)
-b) chip specific formatting
+a) packet formatting (example: vlan, mss, descriptor counting, etc.)
+b) chip-specific formatting
c) enqueueing the packet on a DMA ring
d) IO operations to complete packet transmit, tell DMA engine to chew
-on, tx completion interupts etc
+on, tx completion interrupts, etc.
[For code cleanliness/readability sake, regardless of this work,
one should break the dev->hard_start_xmit() into those 4 functions
anyways].
+
A driver which has all 4 parts and needing to support batching is
advised to split its dev->hard_start_xmit() in the following manner:
-1)use its dev->hard_prep_xmit() method to achieve #a
-2)use its dev->hard_end_xmit() method to achieve #d
-3)#b and #c can stay in ->hard_start_xmit() (or whichever way you
+
+1) use its dev->hard_prep_xmit() method to achieve #a
+2) use its dev->hard_end_xmit() method to achieve #d
+3) #b and #c can stay in ->hard_start_xmit() (or whichever way you
want to do this)
+
Note: There are drivers which may need not support any of the two
-methods (example the tun driver i patched) so the two methods are
+methods (for example, the tun driver I patched), so the two methods are
essentially optional.
2.1.1 Theory of operation
@@ -49,7 +52,7 @@ essentially optional.
The core will first do the packet formatting by invoking your
supplied dev->hard_prep_xmit() method. It will then pass you the packet
-via your dev->hard_start_xmit() method for as many as packets you
+via your dev->hard_start_xmit() method for as many packets as you
have advertised (via dev->xmit_win) you can consume. Lastly it will
invoke your dev->hard_end_xmit() when it completes passing you all the
packets queued for you.
@@ -58,16 +61,16 @@ packets queued for you.
2.1.1.1 Locking rules
---------------------
-dev->hard_prep_xmit() is invoked without holding any
-tx lock but the rest are under TX_LOCK(). So you have to ensure that
-whatever you put it dev->hard_prep_xmit() doesnt require locking.
+dev->hard_prep_xmit() is invoked without holding any tx lock
+but the rest are under TX_LOCK(). So you have to ensure that
+whatever you put it dev->hard_prep_xmit() doesn't require locking.
2.1.1.2 The slippery LLTX
-------------------------
LLTX drivers present a challenge in that we have to introduce a deviation
from the norm and require the ->hard_batch_xmit() method. An LLTX
-driver presents us with ->hard_batch_xmit() to which we pass it a list
+driver presents us with ->hard_batch_xmit() to which we pass in a list
of packets in a dev->blist skb queue. It is then the responsibility
of the ->hard_batch_xmit() to exercise steps #b and #c for all packets
passed in the dev->blist.
@@ -80,11 +83,14 @@ dev->hard_prep_xmit() and dev->hard_end_
dev->xmit_win variable is set by the driver to tell us how
much space it has in its rings/queues. dev->xmit_win is introduced to
ensure that when we pass the driver a list of packets it will swallow
-all of them - which is useful because we dont requeue to the qdisc (and
-avoids burning unnecessary cpu cycles or introducing any strange
+all of them -- which is useful because we don't requeue to the qdisc (and
+avoids burning unnecessary CPU cycles or introducing any strange
re-ordering). The driver tells us, whenever it invokes netif_wake_queue,
how much space it has for descriptors by setting this variable.
+RD: so xmit_win is not total queue size, it's the available queue size
+when calling netif_wake_queue(), right? I guess that's explained below.
+
3.0 Driver Essentials
---------------------
@@ -104,18 +110,18 @@ The typical driver tx state machine is:
-1-> +Cycle repeats and core sends more packets (step 1).
----
-3.1 Driver pre-requisite
+3.1 Driver prerequisite
--------------------------
This is _a very important_ requirement in making batching useful.
-The pre-requisite for batching changes is that the driver should
+The prerequisite for batching changes is that the driver should
provide a low threshold to open up the tx path.
Drivers such as tg3 and e1000 already do this.
Before you invoke netif_wake_queue(dev) you check if there is a
threshold of space reached to insert new packets.
-Heres an example of how i added it to tun driver. Observe the
-setting of dev->xmit_win
+Here's an example of how I added it to tun driver. Observe the
+setting of dev->xmit_win.
---
+#define NETDEV_LTT 4 /* the low threshold to open up the tx path */
@@ -153,14 +159,14 @@ in tg3 code (with no batching changes) l
-----------------
a) On initialization (before netdev registration)
- i) set NETIF_F_BTX in dev->features
- i.e dev->features |= NETIF_F_BTX
+ 1) set NETIF_F_BTX in dev->features
+ i.e., dev->features |= NETIF_F_BTX
This makes the core do proper initialization.
-ii) set dev->xmit_win to something reasonable like
+ 2) set dev->xmit_win to something reasonable like
maybe half the tx DMA ring size etc.
-b) create proper pointer to the new methods desribed above if
+b) create proper pointer to the new methods described above if
you need them.
3.3 Annotation on the different methods
@@ -171,27 +177,30 @@ methods and variable could be used.
3.3.1 The dev->hard_prep_xmit() method
---------------------------------------
-Use this method to only do pre-processing of the skb passed.
-If in the current dev->hard_start_xmit() you are pre-processing
-packets before holding any locks (eg formating them to be put in
-any descriptor etc).
+Use this method only to do preprocessing of the skb passed.
+If in the current dev->hard_start_xmit() you are preprocessing
+packets before holding any locks (e.g., formatting them to be put in
+any descriptor etc.).
+RD: incomplete sentence above.
Look at e1000_prep_queue_frame() for an example.
You may use the skb->cb to store any state that you need to know
-of later when batching.
-PS: I have found when discussing with Michael Chan and Matt Carlson
-that skb->cb[0] (8bytes of it) is used by the VLAN code to pass VLAN
+later when batching.
+
+NOTE: I have found when discussing with Michael Chan and Matt Carlson
+that skb->cb[0] (8 bytes of it) is used by the VLAN code to pass VLAN
info to the driver.
I think this is a violation of the usage of the cb scratch pad.
To work around this, you could use skb->cb[8] or do what the broadcom
-tg3 bacthing driver does which is to glean the vlan info first then
-re-use the skb->cb.
+tg3 batching driver does which is to glean the vlan info first then
+reuse the skb->cb.
3.3.2 dev->hard_start_xmit()
----------------------------
-Heres an example of tx routine that is similar to the one i added
+Here's an example of tx routine that is similar to the one I added
to the current tun driver. bxmit suffix is kept so that you can turn
off batching if needed via and call already existing interface.
+RD: off batching via ethtool if needed ??
----
static int xxx_net_bxmit(struct net_device *dev)
@@ -211,14 +220,14 @@ off batching if needed via and call alre
}
------
-All return codes like NETDEV_TX_OK etc still apply.
+All return codes like NETDEV_TX_OK etc. still apply.
3.3.3 The LLTX batching method, dev->batch_xmit()
-------------------------------------------------
-Heres an example of a batch tx routine that is similar
-to the one i added to the older tun driver. Essentially
-this is what youd do if you wanted to support LLTX.
+Here's an example of a batch tx routine that is similar
+to the one I added to the older tun driver. Essentially
+this is what you would do if you wanted to support LLTX.
----
static int xxx_net_bxmit(struct net_device *dev)
@@ -228,7 +237,7 @@ this is what youd do if you wanted to su
while (skb_queue_len(dev->blist)) {
dequeue from dev->blist
enqueue onto hardware ring
- if hardware ring full break
+ if hardware ring full, break
}
if (hardware ring full) {
@@ -242,34 +251,35 @@ this is what youd do if you wanted to su
}
------
-All return codes like NETDEV_TX_OK etc still apply.
+All return codes like NETDEV_TX_OK etc. still apply.
3.3.4 The tx complete, dev->hard_end_xmit()
-------------------------------------------------
In this method, if there are any IO operations that apply to a
-set of packets such as kicking DMA, setting of interupt thresholds etc,
+set of packets such as kicking DMA, setting of interrupt thresholds etc.,
leave them to the end and apply them once if you have successfully enqueued.
-This provides a mechanism for saving a lot of cpu cycles since IO
+This provides a mechanism for saving a lot of CPU cycles since IO
is cycle expensive.
-For an example of this look e1000 driver e1000_kick_DMA() function.
+For an example of this look at the e1000 driver e1000_kick_DMA() function.
3.3.5 setting the dev->xmit_win
-----------------------------
As mentioned earlier this variable provides hints on how much
data to send from the core to the driver. Here are the obvious ways:
-a)on doing a netif_stop, set it to 1. By default all drivers have
+
+a) on doing a netif_stop, set it to 1. By default all drivers have
this value set to 1 to emulate old behavior where a driver only
receives one packet at a time.
-b)on netif_wake_queue set it to the max available space. You have
+b) on netif_wake_queue set it to the max available space. You have
to be careful if your hardware does scatter-gather since the core
will pass you scatter-gatherable skbs and so you want to at least
leave enough space for the maximum allowed. Look at the tg3 and
e1000 to see how this is implemented.
The variable is important because it avoids the core sending
-any more than what the driver can handle therefore avoiding
+any more than what the driver can handle, therefore avoiding
any need to muck with packet scheduling mechanisms.
Appendix 1: History
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH 2/7] CAN: Add PF_CAN core module
From: Urs Thuermann @ 2007-09-25 21:00 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, David Miller, Patrick McHardy, Joe Perches,
Thomas Gleixner, Oliver Hartkopp, Oliver Hartkopp
In-Reply-To: <20070925083303.6c1f7701@freepuppy.rosehill>
Stephen Hemminger <shemminger@linux-foundation.org> writes:
> Then please make all exported symbols marked EXPORT_SYMBOL_GPL to make
> sure that the other CAN protocol can not reuse your infrastructure.
We don't want to force other CAN protocol implementations to be GPL
also. AFAIR from discussions on LKML, it was mostly agreed upon that
this decision is up to the authors of code.
urs
^ permalink raw reply
* Re: [PATCH 2/7] CAN: Add PF_CAN core module
From: Stephen Hemminger @ 2007-09-25 21:07 UTC (permalink / raw)
To: Urs Thuermann
Cc: netdev, David Miller, Patrick McHardy, Joe Perches,
Thomas Gleixner, Oliver Hartkopp, Oliver Hartkopp
In-Reply-To: <ygfejgmea00.fsf@janus.isnogud.escape.de>
On 25 Sep 2007 23:00:15 +0200
Urs Thuermann <urs@isnogud.escape.de> wrote:
> Stephen Hemminger <shemminger@linux-foundation.org> writes:
>
> > Then please make all exported symbols marked EXPORT_SYMBOL_GPL to
> > make sure that the other CAN protocol can not reuse your
> > infrastructure.
>
> We don't want to force other CAN protocol implementations to be GPL
> also. AFAIR from discussions on LKML, it was mostly agreed upon that
> this decision is up to the authors of code.
>
> urs
I just don't want proprietary drivers extensions in linux kernel.
EXPORT_SYMBOL has no meaning in other OS environments.
^ permalink raw reply
* my plans...
From: David Miller @ 2007-09-25 21:19 UTC (permalink / raw)
To: netdev
I just got back from some travelling this past weekend, so
what I'm going to do today is:
1) Rebase net-2.6.24, that's what I'm doing right now.
I'll be combining bug fixes for feature patches as
much as possible, so this might take most if not all
of this afternoon.
2) After the rebase is done I'll go through the patches
in my backlog for net-2.6.24 which have accumulated.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/7] CAN: Add PF_CAN core module
From: David Miller @ 2007-09-25 21:09 UTC (permalink / raw)
To: urs; +Cc: shemminger, netdev, kaber, joe, tglx, oliver, oliver.hartkopp
In-Reply-To: <ygfejgmea00.fsf@janus.isnogud.escape.de>
From: Urs Thuermann <urs@isnogud.escape.de>
Date: 25 Sep 2007 23:00:15 +0200
> Stephen Hemminger <shemminger@linux-foundation.org> writes:
>
> > Then please make all exported symbols marked EXPORT_SYMBOL_GPL to make
> > sure that the other CAN protocol can not reuse your infrastructure.
>
> We don't want to force other CAN protocol implementations to be GPL
> also. AFAIR from discussions on LKML, it was mostly agreed upon that
> this decision is up to the authors of code.
To a certain extent, yes.
However, the core issue is whether anyone who uses the symbol
is creating a derivative work. If it is pretty clear that this
is the case, you really should mark the exported symbols GPL.
In my opinion, in this case it is pretty clear that any use of
these new symbols would be a derivative work and therefore they
all should be marked GPL.
^ permalink raw reply
* [ofa-general] Re: [PATCH 1/4] [NET_SCHED] explict hold dev tx lock
From: jamal @ 2007-09-25 22:14 UTC (permalink / raw)
To: Stephen Hemminger
Cc: johnpol, kumarkr, herbert, gaagaan, Robert.Olsson, netdev,
rdreier, Waskiewicz Jr, Peter P, mcarlson, kaber, randy.dunlap,
jagana, general, mchan, tgraf, jeff, sri, David Miller
In-Reply-To: <20070925082457.6fec30d6@freepuppy.rosehill>
On Tue, 2007-25-09 at 08:24 -0700, Stephen Hemminger wrote:
> The transmit code path is locked as a code region, rather than just object locking
> on the transmit queue or other fine grained object. This leads to moderately long
> lock hold times when multiple qdisc's and classification is being done.
It will be pretty tricky to optimize that path given the dependencies
between the queues, classifiers, and actions in enqueues; schedulers in
dequeues as well as their config/queries from user space which could
happen concurently on all "N" CPUs.
The txlock optimization i added in patch1 intends to let go of the queue
lock when we enter the dequeue region sooner to reduce the contention.
A further optimization i made was to reduce the time it takes to hold
the tx lock at the driver by moving gunk that doesnt need lock-holding
into the new method dev->hard_end_xmit() (refer to patch #2)
> If we went to finer grain locking it would also mean changes to all network
> devices using the new locking model. My assumption is that we would use
> something like the features flag to do the transition for backward compatibility.
> Take this as a purely "what if" or "it would be nice if" kind of suggestion
> not a requirement or some grand plan.
Ok, hopefully someone would demonstrate how to achieve it; seems a hard
thing to achieve.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH: 2.6.13-15-SMP 3/3] network: concurrently runsoftirqnetwork code on SMP
From: jamal @ 2007-09-25 22:22 UTC (permalink / raw)
To: Stephen Hemminger
Cc: john ye, David Miller, netdev, kuznet, pekkas, jmorris, kaber,
iceburgue
In-Reply-To: <20070925090333.11beebb2@freepuppy.rosehill>
On Tue, 2007-25-09 at 09:03 -0700, Stephen Hemminger wrote:
> There is a standard hash called RSS, that many drivers support because it is
> used by other operating systems.
I think any stateless/simple thing will do (something along the lines
what 802.1ad does for trunk, a 5 classical five tuple etc).
Having solved the reordering problem in such a stateless way introduces
a loadbalancing setback; you may end sending all your packets to one cpu
(a problem Mr Ye didnt have when he was re-orderding ;->).
cheers,
jamal
^ permalink raw reply
* [ofa-general] Re: [DOC] Net batching driver howto
From: jamal @ 2007-09-25 22:28 UTC (permalink / raw)
To: Randy Dunlap
Cc: johnpol, peter.p.waskiewicz.jr, kumarkr, herbert, Jeff Garzik,
Robert.Olsson, netdev, rdreier, mcarlson, David Miller, gaagaan,
jagana, general, mchan, tgraf, sri, shemminger, kaber
In-Reply-To: <20070925131620.617794ae.randy.dunlap@oracle.com>
On Tue, 2007-25-09 at 13:16 -0700, Randy Dunlap wrote:
> On Mon, 24 Sep 2007 18:54:19 -0400 jamal wrote:
>
> > I have updated the driver howto to match the patches i posted yesterday.
> > attached.
>
> Thanks for sending this.
Thank you for reading it Randy.
> This is an early draft, right?
Its a third revision - but you could call it early. When it is done, i
will probably put a pointer to it in some patch.
> I'll fix some typos etc. in it (patch attached) and add some whitespace.
> Please see RD: in the patch for more questions/comments.
Thanks, will do and changes will show up in the next update.
> IMO it needs some changes to eliminate words like "we", "you",
> and "your" (words that personify code). Those words are OK
> when talking about yourself.
The narrative intent is supposed to be i (or someone doing the
description) sitting there with a pen and paper and maybe a laptop and
walking through the details with someone who needs to understand those
details. If you think it is important to make it formal, then by all
means be my guest.
Again, thanks for taking the time.
cheers,
jamal
^ permalink raw reply
* [ofa-general] Re: [PATCH 1/4] [NET_SCHED] explict hold dev tx lock
From: jamal @ 2007-09-25 22:43 UTC (permalink / raw)
To: Stephen Hemminger
Cc: johnpol, kumarkr, herbert, gaagaan, Robert.Olsson, netdev,
rdreier, Waskiewicz Jr, Peter P, mcarlson, kaber, randy.dunlap,
jagana, general, mchan, tgraf, jeff, sri, David Miller
In-Reply-To: <1190758491.4244.15.camel@localhost>
On Tue, 2007-25-09 at 18:15 -0400, jamal wrote:
> A further optimization i made was to reduce the time it takes to hold
> the tx lock at the driver by moving gunk that doesnt need lock-holding
> into the new method dev->hard_end_xmit() (refer to patch #2)
Sorry, that should have read dev->hard_prep_xmit()
cheers,
jamal
^ permalink raw reply
* [PATCH] mv643xx_eth: duplicate methods in initializer
From: Al Viro @ 2007-09-26 0:53 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel, netdev
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
drivers/net/mv643xx_eth.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index 6a117e9..456d1e1 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -2768,8 +2768,6 @@ static const struct ethtool_ops mv643xx_ethtool_ops = {
.get_stats_count = mv643xx_get_stats_count,
.get_ethtool_stats = mv643xx_get_ethtool_stats,
.get_strings = mv643xx_get_strings,
- .get_stats_count = mv643xx_get_stats_count,
- .get_ethtool_stats = mv643xx_get_ethtool_stats,
.nway_reset = mv643xx_eth_nway_restart,
};
--
1.5.3.GIT
^ permalink raw reply related
* Re: [PATCH: 2.6.13-15-SMP 3/3] network: concurrentlyrunsoftirqnetwork code on SMP
From: John Ye @ 2007-09-26 2:12 UTC (permalink / raw)
To: hadi, Stephen Hemminger
Cc: David Miller, netdev, kuznet, pekkas, jmorris, kaber, iceburgue
In-Reply-To: <1190758944.4244.23.camel@localhost>
Jamal & Stephen,
I found BSS-hash paper you mentioned and have browsed it briefly.
The issue "may end sending all your packets to one cpu" might be dealt with
by
cpu hash (srcip + dstip) % nr_cpus, plus checking cpu balance periodically,
shift cpu by an extra seed value?
Any way, the cpu hash code must not be too expensive because every incoming
packet hits the path.
We are going to do further study on this BSS thing.
__do_IRQ has a tendency to collect same IRQ on different CPUs into one CPU
when NIC is busy(by IRQ_PENDING & IRQ_INPROGRESS control skill). so,
dispatch the load to SMP here may be good thing(?).
Thanks.
John Ye
----- Original Message -----
From: "jamal" <hadi@cyberus.ca>
To: "Stephen Hemminger" <shemminger@linux-foundation.org>
Cc: "john ye" <johny@asimco.com.cn>; "David Miller" <davem@davemloft.net>;
<netdev@vger.kernel.org>; <kuznet@ms2.inr.ac.ru>; <pekkas@netcore.fi>;
<jmorris@namei.org>; <kaber@coreworks.de>; <iceburgue@gmail.com>
Sent: Wednesday, September 26, 2007 6:22 AM
Subject: Re: [PATCH: 2.6.13-15-SMP 3/3] network:
concurrentlyrunsoftirqnetwork code on SMP
> On Tue, 2007-25-09 at 09:03 -0700, Stephen Hemminger wrote:
>
> > There is a standard hash called RSS, that many drivers support because
it is
> > used by other operating systems.
>
> I think any stateless/simple thing will do (something along the lines
> what 802.1ad does for trunk, a 5 classical five tuple etc).
>
> Having solved the reordering problem in such a stateless way introduces
> a loadbalancing setback; you may end sending all your packets to one cpu
> (a problem Mr Ye didnt have when he was re-orderding ;->).
>
> cheers,
> jamal
>
>
^ permalink raw reply
* Re: [net-2.6.24][patch 2/2] Dynamically allocate the loopback device
From: David Miller @ 2007-09-26 2:24 UTC (permalink / raw)
To: ebiederm
Cc: pjwaskiewicz, dlezcano, shemminger, netdev, containers,
benjamin.thery
In-Reply-To: <m1r6kwpu9t.fsf@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Mon, 17 Sep 2007 20:44:14 -0600
> David Miller <davem@davemloft.net> writes:
>
> > From: "Peter Waskiewicz" <pjwaskiewicz@gmail.com>
> > Date: Mon, 17 Sep 2007 12:12:24 -0700
> >
> >> This would be a good opportunity to remove the single-allocated queue struct
> >> in netdevice (at the bottom) that we had to put in to accomodate the static
> >> loopback. Now we can set it back to a zero element list, and have
> >> alloc_netdev_mq() just allocate the number of queues requested, not
> >> num_queues - 1.
> >>
> >> I'll put a patch together based on this patchset.
> >
> > Thanks Peter.
> >
> > I'll also let this sit so that Eric can provide any feedback
> > he wants and also figure out how he will use this for the
> > namespace stuff.
>
> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
> Not that it doesn't already have my signed off by.
I've put these patches into the just-rebased net-2.6.24 tree.
I made a minor modification to the second patch, the
out_free_netdev: code in loopback_init() ended like this:
out_free_netdev:
free_netdev(dev);
goto out;
return err;
};
I got rid of the spurious return statement and the trailing
semi-colon after the function closing brace.
Thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox