* Re: [openib-general] [PATCH 5/5] [RFC] Infiniband: connection abstraction
From: Grant Grundler @ 2006-01-18 18:49 UTC (permalink / raw)
To: Sean Hefty; +Cc: Roland Dreier, netdev, linux-kernel, openib-general
In-Reply-To: <43CE8695.9080401@ichips.intel.com>
On Wed, Jan 18, 2006 at 10:19:01AM -0800, Sean Hefty wrote:
> Roland Dreier wrote:
> > > + UCMA_MAX_BACKLOG = 128
> >
> >Is there any reason that we might want to make this a tunable? Maybe
> >as a module parameter that's writable in sysfs...
>
> There's no reason not to make this tunable.
Yes, there are reasons to NOT make something a tunable:
o increases system complexity (admin)
o increases the amount of documentation (learning curve)
o increases test matrix/cost (devel/support cost)
o generally hurts performance (var vs a constant of the same value)
Any reason to make something a tunable has to compensate
for the above drawbacks. An answer to Roland's question
is a reasonable prerequisite if someone wants add a tunable.
IB doesn't have the much in /sys/class/infiniband* or module parameters
and I think that's a Good Thing.
grant
^ permalink raw reply
* wireless: the contenders
From: John W. Linville @ 2006-01-18 20:06 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, jbenc, softmac-dev, bcm43xx-dev
First, the news everyone will like. Thanks to the kernel.org team
I now have a place to publish a wireless tree:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
The tree there has a number of branches, so many that you need
a scorecard...
Branches
--------
The "master" branch of that tree is (mostly) up-to-date w/ Linus, plus
changes I recently sent to Jeff. Those changes are also available on
the "upstream-jgarzik" branch, but it is frozen to when I requested
Jeff's pull.
The tree also has "softmac" and "dscape" branches. The "softmac"
branch includes the Johannes Berg softmac code as well as the the
BCM43xx driver based upon that code. The "dscape" branch includes
the DeviceScape patches from Jiri Benc as well as the BCM43xx driver
ported to the DeviceScape stack.
The fact that the BCM43xx team has ported their driver to both stacks
provides us an excellent opportunity for some objective, "apples to
apples" comparisons between the major stacks. I would like to take
this opportunity to thank them for taking the trouble to do that work
and to make both versions available for comparison.
BTW, those trying to actually use the dscape code will want to poke
around Jiri's kernel.org directories:
http://www.kernel.org/pub/linux/kernel/people/jbenc/
Jiri has some information there that will likely be useful to you.
The other branches are for administrative purposes, and can mostly
be ignored.
Patches
-------
Along with bugfixes and enhancements to the current code (which will
be targeting the "master" branch), I would like to see driver and
stack patches for both the "softmac" and "dscape" branches. I would
like to see what is really out there before making a final call on
which stack to adopt permanently.
If you have an out-of-tree driver which targets either (or both)
stacks, please send patches. If you are working on porting an
in-kernel driver to one of these stacks (either from the other stack
or from its private stack), please send patches. If you have fixes
or enhancements pending for either of these stacks, then please
send patches.
Don't waste any time with your patches. There is good reason to make
a decision quickly, and plenty of pressure to do so. Your code could
be a significant factor in making that decision.
I know that many of you believe that this approach is a bad idea,
for a variety of reasons. I find those arguments valid, and
even persuasive. The point of this exercise is NOT to push two
stacks forward into Linus' kernel. The point is to catalog the
true state of affairs and to collect as large a wireless driver
codebase as possible. You might think of this as a Domesday Book
(http://en.wikipedia.org/wiki/Domesday_Book) for Linux wireless.
Summary
-------
Hopefully the act of collecting these patches will also allow the less
motivated among us to have a chance to evaluate the stacks involved.
There are bound to be some wise and skilled kernel hackers out there
that are just a little too busy to track-down all these patches
themselves... :-)
I appreciate all the commentary and ideas expressed over the past
couple of weeks. I also think the driver writers are doing a good
job with what they've been given so far. I hope this helps to bring
the driver guys in out of the cold, and to put some weight behind
the discussions of where we need to go.
Thanks,
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [Bcm43xx-dev] wireless: the contenders
From: Michael Buesch @ 2006-01-18 20:19 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-kernel, jbenc, softmac-dev, bcm43xx-dev
In-Reply-To: <20060118200616.GC6583@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 618 bytes --]
On Wednesday 18 January 2006 21:06, John W. Linville wrote:
> The tree also has "softmac" and "dscape" branches. The "softmac"
> branch includes the Johannes Berg softmac code as well as the the
> BCM43xx driver based upon that code. The "dscape" branch includes
> the DeviceScape patches from Jiri Benc as well as the BCM43xx driver
> ported to the DeviceScape stack.
Are you going to keep it synced with our repository?
I think it should be possible to automatically send patches for
every change in our tree to you. I am not 100% sure (but 99%).
I will look at it tomorrow.
--
Greetings Michael.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Bcm43xx-dev] wireless: the contenders
From: John W. Linville @ 2006-01-18 20:25 UTC (permalink / raw)
To: Michael Buesch; +Cc: netdev, linux-kernel, jbenc, softmac-dev, bcm43xx-dev
In-Reply-To: <200601182119.20708.mbuesch@freenet.de>
On Wed, Jan 18, 2006 at 09:19:20PM +0100, Michael Buesch wrote:
> On Wednesday 18 January 2006 21:06, John W. Linville wrote:
> > The tree also has "softmac" and "dscape" branches. The "softmac"
> > branch includes the Johannes Berg softmac code as well as the the
> > BCM43xx driver based upon that code. The "dscape" branch includes
> > the DeviceScape patches from Jiri Benc as well as the BCM43xx driver
> > ported to the DeviceScape stack.
>
> Are you going to keep it synced with our repository?
> I think it should be possible to automatically send patches for
> every change in our tree to you. I am not 100% sure (but 99%).
> I will look at it tomorrow.
If you'll send me patches, I'll apply them...
John
P.S. Please do what you can to make them comply w/ kernel patch
posting conventions:
http://linux.yyz.us/patch-format.html
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [PATCH 2/5] [RFC] Infiniband: connection abstraction
From: Bryan O'Sullivan @ 2006-01-18 20:27 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: netdev, openib-general, linux-kernel, Stephen Hemminger
In-Reply-To: <1137568107.3005.69.camel@laptopd505.fenrus.org>
On Wed, 2006-01-18 at 08:08 +0100, Arjan van de Ven wrote:
> the dual license text needs a bit of clarification I suspect to make
> explicit that the "or BSD" part only applies when used entirely outside
> the linux kernel. (that already is the case, just it's not explicit.
> Making that explicit would be good).
One appropriate way to do that would be to mark all IB-related exported
symbols as EXPORT_SYMBOL_GPL.
<b
^ permalink raw reply
* Re: wireless: the contenders
From: Jeff Garzik @ 2006-01-18 20:36 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-kernel, jbenc, softmac-dev, bcm43xx-dev
In-Reply-To: <20060118200616.GC6583@tuxdriver.com>
John W. Linville wrote:
> First, the news everyone will like. Thanks to the kernel.org team
> I now have a place to publish a wireless tree:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
>
> The tree there has a number of branches, so many that you need
> a scorecard...
>
> Branches
> --------
>
> The "master" branch of that tree is (mostly) up-to-date w/ Linus, plus
> changes I recently sent to Jeff. Those changes are also available on
> the "upstream-jgarzik" branch, but it is frozen to when I requested
> Jeff's pull.
Minor git administrative note... In my trees, the 'master' branch is
always vanilla Linus, and I never ever apply my own changes to it. This
enables commands such as
git diff master..upstream > patch
git log master..upstream > log.txt
git log master..upstream | git shortlog > shortlog.txt
to work as expected.
Typically I do not update 'master' unless I am also updating 'upstream'
with vanilla Linus changes, in order to avoid screwing up the tree heads
and the diff. When I do update 'master' from 'upstream', it is a
trivial matter to then pull those changes into 'upstream':
git checkout -f upstream
git pull . master
Regards,
Jeff
^ permalink raw reply
* Re: wireless: the contenders
From: John W. Linville @ 2006-01-18 20:48 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel, jbenc, softmac-dev, bcm43xx-dev
In-Reply-To: <43CEA6EB.6080209@pobox.com>
On Wed, Jan 18, 2006 at 03:36:59PM -0500, Jeff Garzik wrote:
> John W. Linville wrote:
> >The "master" branch of that tree is (mostly) up-to-date w/ Linus, plus
> >changes I recently sent to Jeff. Those changes are also available on
> >the "upstream-jgarzik" branch, but it is frozen to when I requested
> >Jeff's pull.
> Typically I do not update 'master' unless I am also updating 'upstream'
> with vanilla Linus changes, in order to avoid screwing up the tree heads
> and the diff. When I do update 'master' from 'upstream', it is a
> trivial matter to then pull those changes into 'upstream':
Good info...thanks!
FWIW, I have an "origin" branch that corresponds to Linus' tree.
I think that probably enables the same kind of usage as you noted...?
Thanks,
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: wireless: the contenders
From: Jeff Garzik @ 2006-01-18 20:52 UTC (permalink / raw)
To: netdev, linux-kernel, jbenc, softmac-dev, bcm43xx-dev
In-Reply-To: <20060118204844.GE6583@tuxdriver.com>
On Wed, Jan 18, 2006 at 03:48:49PM -0500, John W. Linville wrote:
> On Wed, Jan 18, 2006 at 03:36:59PM -0500, Jeff Garzik wrote:
> > John W. Linville wrote:
>
> > >The "master" branch of that tree is (mostly) up-to-date w/ Linus, plus
> > >changes I recently sent to Jeff. Those changes are also available on
> > >the "upstream-jgarzik" branch, but it is frozen to when I requested
> > >Jeff's pull.
>
> > Typically I do not update 'master' unless I am also updating 'upstream'
> > with vanilla Linus changes, in order to avoid screwing up the tree heads
> > and the diff. When I do update 'master' from 'upstream', it is a
> > trivial matter to then pull those changes into 'upstream':
>
> Good info...thanks!
>
> FWIW, I have an "origin" branch that corresponds to Linus' tree.
> I think that probably enables the same kind of usage as you noted...?
Yep, it doesn't matter what you call it.
I avoid 'origin' since a 'git pull' without arguments will automatically
update that (and possibly master too).
But it's just a name. Any branch with vanilla Linus tree in it will
achieve the behavior I described.
Jeff
^ permalink raw reply
* Repost [PATCH 1 of 3] move destructor to struct neigh_parms
From: Michael S. Tsirkin @ 2006-01-18 21:19 UTC (permalink / raw)
To: openib-general, LKML, netdev
Sorry about reposting: the message didnt seem to make it to netdev.
---
Hi!
struct neigh_ops currently has a destructor field, unused by in-kernel
drivers outside the infiniband subtree.
infiniband ipoib in-tree driver currently uses this field, and we've
run into problems: since the destructor is shared between neighbours
that belong to different net devices, there's no way to set/clear it
safely.
It would be good to know what the design was
behind putting the destructor method there in the first place.
The following patch moves this field to neigh_parms where it can
be safely set, together with its twin neigh_setup.
Two additional patches in the patch series
update ipoib to use this new interface.
Please Cc me on replies, I'm not on the list.
---
Move destructor from neigh_ops (which is shared between devices)
to neigh_parms which is not, so that multiple drivers can set
it safely.
Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
Index: linux-2.6.15/net/core/neighbour.c
===================================================================
--- linux-2.6.15.orig/net/core/neighbour.c 2006-01-12 11:58:15.000000000 +0200
+++ linux-2.6.15/net/core/neighbour.c 2006-01-12 20:10:00.000000000 +0200
@@ -586,8 +586,8 @@ void neigh_destroy(struct neighbour *nei
kfree(hh);
}
- if (neigh->ops && neigh->ops->destructor)
- (neigh->ops->destructor)(neigh);
+ if (neigh->parms->neigh_destructor)
+ (neigh->parms->neigh_destructor)(neigh);
skb_queue_purge(&neigh->arp_queue);
Index: linux-2.6.15/include/net/neighbour.h
===================================================================
--- linux-2.6.15.orig/include/net/neighbour.h 2006-01-03 05:21:10.000000000 +0200
+++ linux-2.6.15/include/net/neighbour.h 2006-01-12 20:09:27.000000000 +0200
@@ -68,6 +68,7 @@ struct neigh_parms
struct net_device *dev;
struct neigh_parms *next;
int (*neigh_setup)(struct neighbour *);
+ void (*neigh_destructor)(struct neighbour *);
struct neigh_table *tbl;
void *sysctl_table;
@@ -145,7 +146,6 @@ struct neighbour
struct neigh_ops
{
int family;
- void (*destructor)(struct neighbour *);
void (*solicit)(struct neighbour *, struct sk_buff*);
void (*error_report)(struct neighbour *, struct sk_buff*);
int (*output)(struct sk_buff*);
--
MST
^ permalink raw reply
* Repost [PATCH 2 of 3] ipoib: move destructor to struct neigh_parms
From: Michael S. Tsirkin @ 2006-01-18 21:19 UTC (permalink / raw)
To: LKML, netdev; +Cc: openib-general
Sorry about reposting: the message didnt seem to make it to netdev.
---
Move destructor from neigh_ops (which is shared between devices)
to neigh_parms which is not, so that multiple drivers can set
it safely.
Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
Index: linux-2.6.15/drivers/infiniband/ulp/ipoib/ipoib_main.c
===================================================================
--- linux-2.6.15.orig/drivers/infiniband/ulp/ipoib/ipoib_main.c 2006-01-12 20:30:52.000000000 +0200
+++ linux-2.6.15/drivers/infiniband/ulp/ipoib/ipoib_main.c 2006-01-12 20:31:26.000000000 +0200
@@ -247,7 +247,6 @@ static void path_free(struct net_device
if (neigh->ah)
ipoib_put_ah(neigh->ah);
*to_ipoib_neigh(neigh->neighbour) = NULL;
- neigh->neighbour->ops->destructor = NULL;
kfree(neigh);
}
@@ -530,7 +529,6 @@ static void neigh_add_path(struct sk_buf
err:
*to_ipoib_neigh(skb->dst->neighbour) = NULL;
list_del(&neigh->list);
- neigh->neighbour->ops->destructor = NULL;
kfree(neigh);
++priv->stats.tx_dropped;
@@ -769,21 +767,9 @@ static void ipoib_neigh_destructor(struc
ipoib_put_ah(ah);
}
-static int ipoib_neigh_setup(struct neighbour *neigh)
-{
- /*
- * Is this kosher? I can't find anybody in the kernel that
- * sets neigh->destructor, so we should be able to set it here
- * without trouble.
- */
- neigh->ops->destructor = ipoib_neigh_destructor;
-
- return 0;
-}
-
static int ipoib_neigh_setup_dev(struct net_device *dev, struct neigh_parms *parms)
{
- parms->neigh_setup = ipoib_neigh_setup;
+ parms->neigh_destructor = ipoib_neigh_destructor;
return 0;
}
--
MST
^ permalink raw reply
* Repost [PATCH 3 of 3] ipoib: fix error handling
From: Michael S. Tsirkin @ 2006-01-18 21:20 UTC (permalink / raw)
To: LKML, netdev; +Cc: openib-general
Sorry about reposting: the message didnt seem to make it to netdev.
---
The following patch is not directly related to the destructor issue,
but I'm posting it here fore completeness since it needs to be applied on top of
the previous pair of patches in the destructor series.
---
Fix error handling in neigh_add_path.
Reduce code duplication by implementing alloc/free functions for ipoib_neigh.
Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
Index: linux-2.6.15/drivers/infiniband/ulp/ipoib/ipoib_main.c
===================================================================
--- linux-2.6.15.orig/drivers/infiniband/ulp/ipoib/ipoib_main.c 2006-01-12 20:48:06.000000000 +0200
+++ linux-2.6.15/drivers/infiniband/ulp/ipoib/ipoib_main.c 2006-01-12 20:48:43.000000000 +0200
@@ -246,8 +246,7 @@ static void path_free(struct net_device
*/
if (neigh->ah)
ipoib_put_ah(neigh->ah);
- *to_ipoib_neigh(neigh->neighbour) = NULL;
- kfree(neigh);
+ ipoib_neigh_free(neigh);
}
spin_unlock_irqrestore(&priv->lock, flags);
@@ -475,7 +474,7 @@ static void neigh_add_path(struct sk_buf
struct ipoib_path *path;
struct ipoib_neigh *neigh;
- neigh = kmalloc(sizeof *neigh, GFP_ATOMIC);
+ neigh = ipoib_neigh_alloc(skb->dst->neighbour);
if (!neigh) {
++priv->stats.tx_dropped;
dev_kfree_skb_any(skb);
@@ -483,8 +482,6 @@ static void neigh_add_path(struct sk_buf
}
skb_queue_head_init(&neigh->queue);
- neigh->neighbour = skb->dst->neighbour;
- *to_ipoib_neigh(skb->dst->neighbour) = neigh;
/*
* We can only be called from ipoib_start_xmit, so we're
@@ -497,7 +494,7 @@ static void neigh_add_path(struct sk_buf
path = path_rec_create(dev,
(union ib_gid *) (skb->dst->neighbour->ha + 4));
if (!path)
- goto err;
+ goto err_path;
__path_add(dev, path);
}
@@ -527,10 +524,9 @@ static void neigh_add_path(struct sk_buf
return;
err:
- *to_ipoib_neigh(skb->dst->neighbour) = NULL;
list_del(&neigh->list);
- kfree(neigh);
-
+err_path:
+ ipoib_neigh_free(neigh);
++priv->stats.tx_dropped;
dev_kfree_skb_any(skb);
@@ -757,8 +753,7 @@ static void ipoib_neigh_destructor(struc
if (neigh->ah)
ah = neigh->ah;
list_del(&neigh->list);
- *to_ipoib_neigh(n) = NULL;
- kfree(neigh);
+ ipoib_neigh_free(neigh);
}
spin_unlock_irqrestore(&priv->lock, flags);
@@ -766,6 +761,26 @@ static void ipoib_neigh_destructor(struc
if (ah)
ipoib_put_ah(ah);
}
+
+struct ipoib_neigh *ipoib_neigh_alloc(struct neighbour *neighbour)
+{
+ struct ipoib_neigh *neigh;
+
+ neigh = kmalloc(sizeof *neigh, GFP_ATOMIC);
+ if (!neigh)
+ return NULL;
+
+ neigh->neighbour = neighbour;
+ *to_ipoib_neigh(neighbour) = neigh;
+
+ return neigh;
+}
+
+void ipoib_neigh_free(struct ipoib_neigh *neigh)
+{
+ *to_ipoib_neigh(neigh->neighbour) = NULL;
+ kfree(neigh);
+}
static int ipoib_neigh_setup_dev(struct net_device *dev, struct neigh_parms *parms)
{
Index: linux-2.6.15/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
===================================================================
--- linux-2.6.15.orig/drivers/infiniband/ulp/ipoib/ipoib_multicast.c 2006-01-12 20:32:08.000000000 +0200
+++ linux-2.6.15/drivers/infiniband/ulp/ipoib/ipoib_multicast.c 2006-01-12 20:48:43.000000000 +0200
@@ -113,8 +113,7 @@ static void ipoib_mcast_free(struct ipoi
*/
if (neigh->ah)
ipoib_put_ah(neigh->ah);
- *to_ipoib_neigh(neigh->neighbour) = NULL;
- kfree(neigh);
+ ipoib_neigh_free(neigh);
}
spin_unlock_irqrestore(&priv->lock, flags);
@@ -720,13 +719,11 @@ out:
if (skb->dst &&
skb->dst->neighbour &&
!*to_ipoib_neigh(skb->dst->neighbour)) {
- struct ipoib_neigh *neigh = kmalloc(sizeof *neigh, GFP_ATOMIC);
+ struct ipoib_neigh *neigh = ipoib_neigh_alloc(skb->dst->neighbour);
if (neigh) {
kref_get(&mcast->ah->ref);
neigh->ah = mcast->ah;
- neigh->neighbour = skb->dst->neighbour;
- *to_ipoib_neigh(skb->dst->neighbour) = neigh;
list_add_tail(&neigh->list, &mcast->neigh_list);
}
}
Index: linux-2.6.15/drivers/infiniband/ulp/ipoib/ipoib.h
===================================================================
--- linux-2.6.15.orig/drivers/infiniband/ulp/ipoib/ipoib.h 2006-01-12 20:27:47.000000000 +0200
+++ linux-2.6.15/drivers/infiniband/ulp/ipoib/ipoib.h 2006-01-12 20:48:43.000000000 +0200
@@ -222,6 +222,9 @@ static inline struct ipoib_neigh **to_ip
(offsetof(struct neighbour, ha) & 4));
}
+struct ipoib_neigh *ipoib_neigh_alloc(struct neighbour *neigh);
+void ipoib_neigh_free(struct ipoib_neigh *neigh);
+
extern struct workqueue_struct *ipoib_workqueue;
/* functions */
--
MST
^ permalink raw reply
* Re: Fwd: [PATCH 1 of 3] move destructor to struct neigh_parms
From: Michael S. Tsirkin @ 2006-01-18 21:27 UTC (permalink / raw)
To: Shirley Ma; +Cc: netdev, openib-general-bounces, LKML, openib-general
In-Reply-To: <OFB2D358DB.F7A4CFB5-ON872570FA.007138E4-882570FA.00714019@us.ibm.com>
Quoting Shirley Ma <xma@us.ibm.com>:
> Subject: Re: Fwd: [PATCH 1 of 3] move destructor to struct neigh_parms
>
>
> >+ if (neigh->parms->neigh_destructor)
> >+ (neigh->parms->neigh_destructor)(neigh);
>
> Is that safe without checking neigh->parms here?
Yes, we have neigh_parms_put(neigh->parms); a couple of lines below.
--
MST
^ permalink raw reply
* Re: [git patches] e1000 fixes
From: Andrew Morton @ 2006-01-18 22:11 UTC (permalink / raw)
To: Jeff Garzik; +Cc: torvalds, netdev, linux-kernel
In-Reply-To: <20060118212449.GA13260@havoc.gtf.org>
Jeff Garzik <jgarzik@pobox.com> wrote:
>
> Let's see how this goes... if there are further problems, I'll just
> revert the entire thing, and push these changes (and the previous set)
> into upstream-2.6.17 branch.
>
> I don't mind them updating the defconfig files, even though most people
> are too slack to worry about it, since its pretty clear the default
> choice.
>
>
> Please pull from 'upstream-fixes' branch of
> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
These patches fix e1000 for me, thanks.
^ permalink raw reply
* [patch 1/2] MAINTAINERS: correct location for net-2.6.git
From: John W. Linville @ 2006-01-18 22:43 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, davem
Correct location info for net-2.6 git tree.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
MAINTAINERS | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6d1b048..0d0f8a8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1841,7 +1841,7 @@ M: yoshfuji@linux-ipv6.org
P: Patrick McHardy
M: kaber@coreworks.de
L: netdev@vger.kernel.org
-T: git kernel.org:/pub/scm/linux/kernel/davem/net-2.6.git
+T: git kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git
S: Maintained
IPVS
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply related
* [patch 2/2] MAINTAINERS: add entry for wireless networking
From: John W. Linville @ 2006-01-18 22:44 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, davem
In-Reply-To: <20060118224300.GF6583@tuxdriver.com>
Add an entry to MAINTAINERS for wireless networking, just so people
know whom to bless with patches.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
MAINTAINERS | 7 +++++++
1 files changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6d1b048..23aca6f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1844,6 +1844,13 @@ L: netdev@vger.kernel.org
T: git kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git
S: Maintained
+NETWORKING [WIRELESS]
+P: John W. Linville
+M: linville@tuxdriver.com
+L: netdev@vger.kernel.org
+T: git kernel.org:/pub/scm/linux/kernel/git/linville/wireless-2.6.git
+S: Maintained
+
IPVS
P: Wensong Zhang
M: wensong@linux-vs.org
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply related
* Re: [patch 2/2] MAINTAINERS: add entry for wireless networking
From: David S. Miller @ 2006-01-18 22:53 UTC (permalink / raw)
To: linville; +Cc: linux-kernel, netdev
In-Reply-To: <20060118224453.GG6583@tuxdriver.com>
Both applied, thanks John.
^ permalink raw reply
* Re: [Bcm43xx-dev] wireless: the contenders
From: Johannes Berg @ 2006-01-19 0:19 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-kernel, jbenc, softmac-dev, bcm43xx-dev
In-Reply-To: <20060118200616.GC6583@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 488 bytes --]
On Wed, 2006-01-18 at 15:06 -0500, John W. Linville wrote:
> The tree also has "softmac" and "dscape" branches. The "softmac"
> branch includes the Johannes Berg softmac code as well as the the
> BCM43xx driver based upon that code.
I guess that branch also contains my enhancements to ieee80211, do you
have any intentions of pulling those over to your upstream tree? I
suppose I should rather post them as a series of patches to netdev for
wider consideration.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Arnd Bergmann @ 2006-01-19 0:57 UTC (permalink / raw)
To: spereira
Cc: YOSHIFUJI Hideaki / 吉藤英明, acme, ak,
linux-kernel, netdev, pereira.shaun, Arnd Bergmann
In-Reply-To: <1137567396.14130.2.camel@spereira05.tusc.com.au>
Am Wednesday 18 January 2006 07:56 schrieb Shaun Pereira:
> Assuming you are happy with the state of the patches, is there anyway
> for me to know if they will become a part of the next release?
I don't see any more technical problems with your patches. You still need
to proper patch description and Signed-off-by: line like it is described
in Documentation/SubmittingPatches.
You can add an 'Acked-by: Arnd Bergmann <arnd@arndb.de>' line to the four
patches you posted last if you like.
> Usually submitted/reviewed patches to netdev does not not always
> guarantee they will be acccepted/signed-off.
> Any advice would be useful
I'm not that familiar with the process for non-driver patches for netdev
(nor for device drivers as it seems ;-)), but my understanding is that you
should address those to Jeff Garzik as well, asking for inclusion in the
netdev-2.6 git tree in your introductory '[PATCH 0/4]' mail.
Since the official merge window for 2.6.16 is now over (2.6.16-rc1 has been
released), it may have to wait for 2.6.17 to become part of the mainline
kernel, that probably depends on Jeffs judgement.
I would think it can still go in since it is a bug fix for the execution of
32 bit programs using x25 ioctls, but it's clearly not my decision ;-).
Arnd <><
^ permalink raw reply
* Re: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: David S. Miller @ 2006-01-19 1:05 UTC (permalink / raw)
To: arnd; +Cc: spereira, yoshfuji, acme, ak, linux-kernel, netdev, pereira.shaun
In-Reply-To: <200601190157.38277.arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 19 Jan 2006 01:57:37 +0100
> I'm not that familiar with the process for non-driver patches for
> netdev (nor for device drivers as it seems ;-)), but my
> understanding is that you should address those to Jeff Garzik as
> well, asking for inclusion in the netdev-2.6 git tree in your
> introductory '[PATCH 0/4]' mail.
Those should be CC:'d to me, not Jeff, he has enough to review
and merge :)
^ permalink raw reply
* [2.6 patch] schedule SHAPER for removal
From: Adrian Bunk @ 2006-01-19 2:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: Alan Cox, jgarzik, netdev, linux-kernel
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
This patch was already sent on:
- 13 Jan 2006
--- linux-2.6.15-mm3-full/Documentation/feature-removal-schedule.txt.old 2006-01-13 15:02:15.000000000 +0100
+++ linux-2.6.15-mm3-full/Documentation/feature-removal-schedule.txt 2006-01-13 15:06:19.000000000 +0100
@@ -164,0 +165,6 @@
+---------------------------
+
+What: Traffic Shaper (CONFIG_SHAPER)
+When: July 2006
+Why: obsoleted by the code in net/sched/
+Who: Adrian Bunk <bunk@stusta.de
--- linux-2.6.15-mm3-full/drivers/net/Kconfig.old 2006-01-13 15:06:34.000000000 +0100
+++ linux-2.6.15-mm3-full/drivers/net/Kconfig 2006-01-13 15:06:49.000000000 +0100
@@ -2663,7 +2663,7 @@
"SCSI generic support".
config SHAPER
- tristate "Traffic Shaper (EXPERIMENTAL)"
+ tristate "Traffic Shaper (OBSOLETE)"
depends on EXPERIMENTAL
---help---
The traffic shaper is a virtual network device that allows you to
^ permalink raw reply
* Re: [Bcm43xx-dev] wireless: the contenders
From: John W. Linville @ 2006-01-19 15:27 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-kernel, jbenc, softmac-dev, bcm43xx-dev
In-Reply-To: <1137629980.4385.9.camel@localhost>
On Thu, Jan 19, 2006 at 01:19:40AM +0100, Johannes Berg wrote:
> On Wed, 2006-01-18 at 15:06 -0500, John W. Linville wrote:
>
> > The tree also has "softmac" and "dscape" branches. The "softmac"
> > branch includes the Johannes Berg softmac code as well as the the
> > BCM43xx driver based upon that code.
>
> I guess that branch also contains my enhancements to ieee80211, do you
> have any intentions of pulling those over to your upstream tree? I
> suppose I should rather post them as a series of patches to netdev for
> wider consideration.
I pulled from the softmac-2.6.git tree. I think there was ieee80211
stuff in there as well, but you probably know better than I do. :-)
The history in your tree isn't formatted properly for the kernel,
so something would have to be done before that went upstream anyway.
I think it would be best for you to post the patches to netdev,
including patches covering softmac if you are so inclined. Please be
sure to follow kernel patch posting conventions:
http://linux.yyz.us/patch-format.html
Thanks,
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: My vote against eepro* removal
From: Adrian Bunk @ 2006-01-19 16:20 UTC (permalink / raw)
To: kus Kusche Klaus
Cc: Lee Revell, linux-kernel, john.ronciak, ganesh.venkatesan,
jesse.brandeburg, netdev
In-Reply-To: <AAD6DA242BC63C488511C611BD51F367323322@MAILIT.keba.co.at>
On Thu, Jan 19, 2006 at 11:26:51AM +0100, kus Kusche Klaus wrote:
> > From: Lee Revell
> > On Thu, 2006-01-19 at 08:19 +0100, kus Kusche Klaus wrote:
> > > Last time I tested (around 2.6.12), eepro100 worked much better
> > > in -rt kernels w.r.t. latencies than e100:
> > >
> > > e100 caused a periodic latency of about 500 microseconds
> > > exactly every 2 seconds, no matter what the load on the interface
> > > was (i.e. even on an idle interface).
> > >
> > > eepro100 did not show any latencies that long, it worked much
> > > smoother w.r.t. latencies.
> > >
> > > Of course I would prefer to have e100 fixed over keeping eepro100
> > > around forever, but the last time I checked, it still wasn't fixed.
> >
> > Please provide latency traces to illustrate the problematic code path.
>
> It's not a "latency": As far as I can tell, interrupts or preemption
> are not disabled, the latency tracer doesn't show anything.
>
> I just noticed that low-pri rt processes did not get scheduled for
> about 500 microseconds when e100 was active (even if the net was
> idle), and that there were no such breaks with eepro100.
>
> I didn't analyze it in detail at that time, I believed that the e100
> interrupt handler thread was running every 2 seconds for 500
> microseconds, because the interrupt count of eth0 incremented every
> 2 seconds, exactly when my rt processes paused.
>
> This would be bad: That irq thread is at rt prio 47 on my system,
> above many importent things.
>
> However, I checked more closely now, and found out that only a small
> portion of the 500 microseconds is spent in the irq thread. Most of
> it is spent in the timer thread, at rt prio 1, so the whole thing
> is a much smaller problem than I originally believed.
>
> Must be the function e100_watchdog.
>...
Is this with 2.6.12 or 2.6.16-rc1?
If it's the former, please check whether the problem is still presnt in
the latter.
If it's the latter, I'm sure the e100 developers (Cc'ed) are interested
in your problem.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: help with e1000 issue?
From: Christopher Friesen @ 2006-01-19 16:48 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: netdev, e1000-devel
In-Reply-To: <4807377b0601181316w2ac0fb0dod976e456816331ae@mail.gmail.com>
Jesse Brandeburg wrote:
> On 1/18/06, Christopher Friesen <cfriesen@nortel.com> wrote:
>>So, somehow we're getting into a state where we can't receive packets,
>>and we're never getting out of that state.
> Are you sure that you're able to transmit and you aren't just handing
> it to the hardware and it never gets out? tcpdump on a remote machine
> would verify.
I haven't tried the new driver yet, so this is still with the old driver
(had the hung machine still up from yesterday).
It looks like tx is working--we see the packets on the other machines on
the network. I tested unicast and broadcast, and both seem to be working.
I tried a broadcast ping to the whole subnet. For that one the icmp
packet goes out, then we see ARPs from everyone on the subnet trying to
get the MAC address of the machine with eth issues.
On the machine with hung ethernet:
root@172.24.101.12:/root> ping -b 172.25.0.0
WARNING: pinging broadcast address
PING 172.25.0.0 (172.25.0.0) 56(84) bytes of data.
64 bytes from 172.25.101.12: icmp_seq=1 ttl=64 time=0.041 ms
64 bytes from 172.25.101.12: icmp_seq=2 ttl=64 time=0.046 ms
On the other machine:
root@10.102.92.28:/root> tcpdump -n -i bond1 host 172.25.101.12
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond1, link-type EN10MB (Ethernet), capture size 96 bytes
01:51:27.275594 IP 172.25.101.12 > 172.25.0.0: icmp 64: echo request seq 1
01:51:27.275748 arp who-has 172.25.101.12 tell 172.25.80.0
01:51:27.275824 arp who-has 172.25.101.12 tell 172.25.101.16
01:51:27.276248 arp who-has 172.25.101.12 tell 172.25.101.13
01:51:27.276373 arp who-has 172.25.101.12 tell 172.25.101.1
01:51:28.275674 arp who-has 172.25.101.12 tell 172.25.101.16
01:51:28.276258 arp who-has 172.25.101.12 tell 172.25.101.1
01:51:28.278017 arp who-has 172.25.101.12 tell 172.25.80.0
01:51:28.278260 IP 172.25.101.12 > 172.25.0.0: icmp 64: echo request seq 2
01:51:28.278388 arp who-has 172.25.101.12 tell 172.25.101.13
01:51:29.275520 arp who-has 172.25.101.12 tell 172.25.101.16
01:51:29.276018 arp who-has 172.25.101.12 tell 172.25.101.1
01:51:29.280032 IP 172.25.101.12 > 172.25.0.0: icmp 64: echo request seq 3
01:51:29.280277 arp who-has 172.25.101.12 tell 172.25.80.0
01:51:29.280524 arp who-has 172.25.101.12 tell 172.25.101.13
Chris
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
^ permalink raw reply
* Re: My vote against eepro* removal
From: John Ronciak @ 2006-01-19 17:16 UTC (permalink / raw)
To: Adrian Bunk
Cc: kus Kusche Klaus, Lee Revell, linux-kernel, john.ronciak,
ganesh.venkatesan, jesse.brandeburg, netdev
In-Reply-To: <20060119162056.GP19398@stusta.de>
During the watchdog the e100 driver reads all of the status registers
from the actual hardware. There are 26 (worst case) register reads.
There is also a spin lock for another check in the watchdog. It would
still surprise me that all of this would take 500 usec. If you are
seeing this delay, you can comment out the scheduling of the watchdog
to see if this goes away. We'll need to narrow down exactly what in
the watchdog is causing the delay
Thanks.
--
Cheers,
John
^ permalink raw reply
* Re: [2.6 patch] schedule SHAPER for removal
From: Jan Engelhardt @ 2006-01-19 20:18 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, Alan Cox, jgarzik, netdev, linux-kernel
In-Reply-To: <20060119021150.GC19398@stusta.de>
>Subject: [2.6 patch] schedule SHAPER for removal
Replaced by what; the QoS subsystem?
> config SHAPER
>- tristate "Traffic Shaper (EXPERIMENTAL)"
>+ tristate "Traffic Shaper (OBSOLETE)"
> depends on EXPERIMENTAL
Jan Engelhardt
--
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/
^ 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