* Re: [PATCH 1/2] e1000: fix netpoll with NAPI
From: John W. Linville @ 2006-06-15 12:44 UTC (permalink / raw)
To: Mitch Williams
Cc: Neil Horman, Jeff Moyer, Kok, Auke-jan H, Matt Mackall,
Garzik, Jeff, netdev, Brandeburg, Jesse, Kok, Auke
In-Reply-To: <Pine.CYG.4.58.0606141635440.2888@mawilli1-desk2.amr.corp.intel.com>
On Wed, Jun 14, 2006 at 04:44:56PM -0700, Mitch Williams wrote:
> One of our engineers (on the I/O AT team) has been tasked with modifying
> the Linux kernel to properly support multiple hardware queues (both TX and
> RX). We'll make sure that he looks at the netpoll interface as part of
> that process.
Might I ask who this is? I might like to ping him/her on this topic.
There is potentially some overlap with wireless, at least on the
transmit side.
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [Ubuntu PATCH] Broadcom wireless patch, PCIE/Mactel support
From: Stefano Brivio @ 2006-06-15 11:32 UTC (permalink / raw)
To: Randy Dunlap; +Cc: lkml, netdev, mb, akpm
In-Reply-To: <44909A3F.4090905@oracle.com>
On Wed, 14 Jun 2006 16:22:39 -0700
Randy Dunlap <randy.dunlap@oracle.com> wrote:
> From: Matthew Garrett <mjg59@srcf.ucam.org>
>
> Broadcom wireless patch, PCIE/Mactel support
>
> http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commitdiff;h=1373a8487e911b5ee204f4422ddea00929c8a4cc
>
> This patch adds support for PCIE cores to the bcm43xx driver. This is
> needed for wireless to work on the Intel imacs. I've submitted it to
> bcm43xx upstream.
NACK.
This has been superseded by my patchset:
http://www.mail-archive.com/bcm43xx-dev@lists.berlios.de/msg01267.html
I'm still waiting for more testing so I didn't request merging to mainline
yet. Plus, this patch is copied from this one:
http://www.mail-archive.com/bcm43xx-dev@lists.berlios.de/msg00919.html
which is wrong. Please see my patchset and new specs for reference.
PS: Next time, don't be rude and send patches to the maintainers.
--
Ciao
Stefano
^ permalink raw reply
* Re: [patch] ipv4: fix lock usage in udp_ioctl
From: Ingo Molnar @ 2006-06-15 10:52 UTC (permalink / raw)
To: Heiko Carstens
Cc: Herbert Xu, davem, jgarzik, akpm, linux-kernel, netdev, fpavlic
In-Reply-To: <20060615065531.GA10411@osiris.ibm.com>
* Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> How about the patch below? The warning goes away and I assume
> "tmp_list" needs lockdep_reinit_key too, since it should have the same
> locking rules as the rest of qeth's skb-queue management.
yeah, looks good.
Ingo
^ permalink raw reply
* Re: [PATCH 0/2] Runtime configuration of HTB's HYSTERESIS option
From: Martin Devera @ 2006-06-15 9:49 UTC (permalink / raw)
To: Russell Stuart
Cc: Jamal Hadi Salim, Stephen Hemminger, netdev, lartc,
Jesper Dangaard Brouer
In-Reply-To: <1150362059.5578.13.camel@ras.pc.brisbane.lube>
Russell Stuart wrote:
> The HTB qdisc has a compile time option, HTB_HYSTERESIS,
> that trades accuracy of traffic classification for CPU
> time. These patches change hysteresis to be a runtime
> option under the control of "tc".
>
> The effects of HYSTERESIS on HTB's accuracy are significant
> (see chapter 7, section 7.3.1, pp 69-70 in Jesper Brouer's
> thesis: http://www.adsl-optimizer.dk/thesis/ ), whereas
> HTB's CPU usage on modern machines using broadband links
> is minimal. Currently HYSTERESIS is on by default, and
> requires a kernel re-compile to change. Altering it to
> be a runtime option will make life easier for the bulk of
> its users.
At time of HTB implementation I needed to reach 100MBit speed on
relatively slow box. The hysteresis was a way. On other side I used
hand-made TSC based measure tool to compute exact (15%) performance
gain. Today I'd measure it using oprofile.
When rethinking it again I'd suggest to re-measure real performance
impact for both flat and deep class hierarchy and consider switching the
hysteresis off by default (or even to remove the code if the gain is
negligible). If it is the case then it is the cleanest solution IMHO.
On other side I see no problem with attached patches. Have you tested
patched kernel with old "tc" tool ?
thanks for your effort,
Martin
^ permalink raw reply
* Re: driver for pptp
From: xeb @ 2006-06-15 9:49 UTC (permalink / raw)
To: netdev
Thanks for critique.
>Please read Documentation/SubmittingPatches (and CodingStyle) and submit your kernel patch to netdev.
OK.
>1) why wasn't it possible to use the PPPoX infrastructure of the kernel which is already being used by PPPoE ? Or at least model it somehow similar to the existing PPPoE/PPPoX infrastructure?
I agree, I will rebuild module.
>2) why are you using a timer for asynchronous processing of GRE frames?
First of all, why does it have to happen asynchronously at all?
Secondly, why using a timer when there's nothing time related (or do
I miss something)? If deferred, out-of-context execution is
required, there are other primitives such as tasklets.
Because it is the mechanism of processing reordered packets. On timeout (i.e. there was a loss of packets) buffered packets continue to be processed. It for reduction of traffic if client is under firewall which may reorder packets.
>3) you conflict with the ip_gre.c genric GRE encapsulation driver. this
is because both want to reigster a proto handler for GRE. Ideally,
there needs to be another demultiplex between the GRE protocl and its
users. The code registered for GRE would look at the packet and
determine whether e.g. it is a PPTP GRE packet and then pass it on to
the pptp module.
I contacted to the developer ip_gre.c and it has told too most but while there are no results.
4) your code doesn't look nonlinear skb clean
Please give me more comments.
5) why did you chose to implement /dev/pptp rather than a socket family
like the existing pppox/pppoe code?
I agree, I will rebuild module.
^ permalink raw reply
* [PATCH 2/2] Runtime configuration of HTB's HYSTERESIS option (userspace)
From: Russell Stuart @ 2006-06-15 9:01 UTC (permalink / raw)
To: Jamal Hadi Salim, Stephen Hemminger, Martin Devera, netdev, lartc
Cc: Jesper Dangaard Brouer
[-- Attachment #1: Type: text/plain, Size: 4893 bytes --]
The HTB qdisc has a compile time option, HTB_HYSTERESIS,
that trades accuracy of traffic classification for CPU
time. These patches change hysteresis to be a runtime
option under the control of "tc".
The effects of HYSTERESIS on HTB's accuracy are significant
(see chapter 7, section 7.3.1, pp 69-70 in Jesper Brouer's
thesis: http://www.adsl-optimizer.dk/thesis/ ), whereas
HTB's CPU usage on modern machines using broadband links
is minimal. Currently HYSTERESIS is on by default, and
requires a kernel re-compile to change. Altering it to
be a runtime option will make life easier for the bulk of
its users.
Further documentation on the patch and its usage can be
found here:
http://www.stuart.id.au/russell/files/tc/tc-atm
Signed-off-by: Russell Stuart <russell-tcatm@stuart.id.au>
Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
---
diff -Nurp iproute2.orig/include/linux/pkt_sched.h iproute2/include/linux/pkt_sched.h
--- iproute2.orig/include/linux/pkt_sched.h 2006-06-13 11:53:27.000000000 +1000
+++ iproute2/include/linux/pkt_sched.h 2006-06-13 11:54:50.000000000 +1000
@@ -232,6 +232,10 @@ struct tc_gred_sopt
#define TC_HTB_MAXDEPTH 8
#define TC_HTB_PROTOVER 3 /* the same as HTB and TC's major */
+struct tc_htb_hopt
+{
+ __u32 nohyst;
+};
struct tc_htb_opt
{
struct tc_ratespec rate;
@@ -259,6 +263,7 @@ enum
TCA_HTB_INIT,
TCA_HTB_CTAB,
TCA_HTB_RTAB,
+ TCA_HTB_NOHYST,
__TCA_HTB_MAX,
};
diff -Nurp iproute2.orig/tc/q_htb.c iproute2/tc/q_htb.c
--- iproute2.orig/tc/q_htb.c 2006-06-13 11:53:27.000000000 +1000
+++ iproute2/tc/q_htb.c 2006-06-13 11:54:50.000000000 +1000
@@ -35,7 +35,7 @@ static void explain(void)
" r2q DRR quantums are computed as rate in Bps/r2q {10}\n"
" debug string of 16 numbers each 0-3 {0}\n\n"
"... class add ... htb rate R1 [burst B1] [mpu B] [overhead O] [atm]\n"
- " [prio P] [slot S] [pslot PS]\n"
+ " [prio P] [slot S] [pslot PS] [nohyst]\n"
" [ceil R2] [cburst B2] [mtu MTU] [quantum Q]\n"
" rate rate allocated to this class (class can still borrow)\n"
" burst max bytes burst which can be accumulated during idle period {computed}\n"
@@ -46,6 +46,7 @@ static void explain(void)
" cburst burst but for ceil {computed}\n"
" mtu max packet size we create rate map for {1600}\n"
" prio priority of leaf; lower are served first {0}\n"
+ " nohyst disable hysteresis (heavier on CPU but more accurate)\n"
" quantum how much bytes to serve from leaf at once {use r2q}\n"
"\nTC HTB version %d.%d\n",HTB_TC_VER>>16,HTB_TC_VER&0xffff
);
@@ -104,6 +105,7 @@ static int htb_parse_class_opt(struct qd
{
int ok=0;
struct tc_htb_opt opt;
+ struct tc_htb_hopt hopt;
__u32 rtab[256],ctab[256];
unsigned buffer=0,cbuffer=0;
int cell_log=-1,ccell_log = -1;
@@ -114,6 +116,7 @@ static int htb_parse_class_opt(struct qd
struct rtattr *tail;
memset(&opt, 0, sizeof(opt)); mtu = 1600; /* eth packet len */
+ memset(&hopt, 0, sizeof(hopt));
while (argc > 0) {
if (matches(*argv, "prio") == 0) {
@@ -132,6 +135,8 @@ static int htb_parse_class_opt(struct qd
if (get_u8(&mpu8, *argv, 10)) {
explain1("mpu"); return -1;
}
+ } else if (matches(*argv, "nohyst") == 0) {
+ hopt.nohyst = 1;
} else if (matches(*argv, "overhead") == 0) {
NEXT_ARG();
if (get_s8(&overhead, *argv, 10)) {
@@ -221,14 +226,16 @@ static int htb_parse_class_opt(struct qd
addattr_l(n, 2024, TCA_HTB_PARMS, &opt, sizeof(opt));
addattr_l(n, 3024, TCA_HTB_RTAB, rtab, 1024);
addattr_l(n, 4024, TCA_HTB_CTAB, ctab, 1024);
+ addattr_l(n, 5024, TCA_HTB_NOHYST, &hopt, sizeof(hopt));
tail->rta_len = (void *) NLMSG_TAIL(n) - (void *) tail;
return 0;
}
static int htb_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
{
- struct rtattr *tb[TCA_HTB_RTAB+1];
+ struct rtattr *tb[TCA_HTB_MAX+1];
struct tc_htb_opt *hopt;
+ struct tc_htb_hopt *uhopt;
struct tc_htb_glob *gopt;
double buffer,cbuffer;
SPRINT_BUF(b1);
@@ -238,7 +245,7 @@ static int htb_print_opt(struct qdisc_ut
if (opt == NULL)
return 0;
- parse_rtattr_nested(tb, TCA_HTB_RTAB, opt);
+ parse_rtattr_nested(tb, TCA_HTB_MAX, opt);
if (tb[TCA_HTB_PARMS]) {
@@ -278,6 +285,13 @@ static int htb_print_opt(struct qdisc_ut
fprintf(f, "buffer [%08x] cbuffer [%08x] ",
hopt->buffer,hopt->cbuffer);
}
+ if (tb[TCA_HTB_NOHYST]) {
+ uhopt = RTA_DATA(tb[TCA_HTB_NOHYST]);
+ if (RTA_PAYLOAD(tb[TCA_HTB_NOHYST]) < sizeof(*uhopt)) return -1;
+
+ if (uhopt->nohyst)
+ fprintf(f, "nohyst ");
+ }
if (tb[TCA_HTB_INIT]) {
gopt = RTA_DATA(tb[TCA_HTB_INIT]);
if (RTA_PAYLOAD(tb[TCA_HTB_INIT]) < sizeof(*gopt)) return -1;
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 1/2] Runtime configuration of HTB's HYSTERESIS option (kernel)
From: Russell Stuart @ 2006-06-15 9:01 UTC (permalink / raw)
To: Jamal Hadi Salim, Stephen Hemminger, Martin Devera, netdev, lartc
Cc: Jesper Dangaard Brouer
[-- Attachment #1: Type: text/plain, Size: 5285 bytes --]
The HTB qdisc has a compile time option, HTB_HYSTERESIS,
that trades accuracy of traffic classification for CPU
time. These patches change hysteresis to be a runtime
option under the control of "tc".
The effects of HYSTERESIS on HTB's accuracy are significant
(see chapter 7, section 7.3.1, pp 69-70 in Jesper Brouer's
thesis: http://www.adsl-optimizer.dk/thesis/ ), whereas
HTB's CPU usage on modern machines using broadband links
is minimal. Currently HYSTERESIS is on by default, and
requires a kernel re-compile to change. Altering it to
be a runtime option will make life easier for the bulk of
its users.
Further documentation on the patch and its usage can be
found here:
http://www.stuart.id.au/russell/files/tc/tc-atm
Signed-off-by: Russell Stuart <russell-tcatm@stuart.id.au>
Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
---
diff -Nurp kernel-source-2.6.11.orig/include/linux/pkt_sched.h kernel-source-2.6.11/include/linux/pkt_sched.h
--- kernel-source-2.6.11.orig/include/linux/pkt_sched.h 2005-03-02 17:38:13.000000000 +1000
+++ kernel-source-2.6.11/include/linux/pkt_sched.h 2006-06-13 11:34:25.000000000 +1000
@@ -231,6 +231,10 @@ struct tc_gred_sopt
#define TC_HTB_MAXDEPTH 8
#define TC_HTB_PROTOVER 3 /* the same as HTB and TC's major */
+struct tc_htb_hopt
+{
+ __u32 nohyst;
+};
struct tc_htb_opt
{
struct tc_ratespec rate;
@@ -258,6 +262,7 @@ enum
TCA_HTB_INIT,
TCA_HTB_CTAB,
TCA_HTB_RTAB,
+ TCA_HTB_NOHYST,
__TCA_HTB_MAX,
};
diff -Nurp kernel-source-2.6.11.orig/net/sched/sch_htb.c kernel-source-2.6.11/net/sched/sch_htb.c
--- kernel-source-2.6.11.orig/net/sched/sch_htb.c 2005-03-02 17:38:12.000000000 +1000
+++ kernel-source-2.6.11/net/sched/sch_htb.c 2006-06-13 11:34:25.000000000 +1000
@@ -73,7 +73,6 @@
#define HTB_EWMAC 2 /* rate average over HTB_EWMAC*HTB_HSIZE sec */
#undef HTB_DEBUG /* compile debugging support (activated by tc tool) */
#define HTB_RATECM 1 /* whether to use rate computer */
-#define HTB_HYSTERESIS 1/* whether to use mode hysteresis for speedup */
#define HTB_QLOCK(S) spin_lock_bh(&(S)->dev->queue_lock)
#define HTB_QUNLOCK(S) spin_unlock_bh(&(S)->dev->queue_lock)
#define HTB_VER 0x30011 /* major must be matched with number suplied by TC as version */
@@ -190,6 +189,7 @@ struct htb_class
/* class attached filters */
struct tcf_proto *filter_list;
int filter_cnt;
+ int nohyst; /* Don't use hysteresis htb_class_mode */
int warned; /* only one warning about non work conserving .. */
@@ -622,20 +622,14 @@ static __inline__ enum htb_cmode
htb_class_mode(struct htb_class *cl,long *diff)
{
long toks;
+ long hysteresis =
+ (cl->nohyst || cl->cmode == HTB_CANT_SEND) ? 0 : -cl->cbuffer;
- if ((toks = (cl->ctokens + *diff)) < (
-#if HTB_HYSTERESIS
- cl->cmode != HTB_CANT_SEND ? -cl->cbuffer :
-#endif
- 0)) {
+ if ((toks = (cl->ctokens + *diff)) < hysteresis) {
*diff = -toks;
return HTB_CANT_SEND;
}
- if ((toks = (cl->tokens + *diff)) >= (
-#if HTB_HYSTERESIS
- cl->cmode == HTB_CAN_SEND ? -cl->buffer :
-#endif
- 0))
+ if ((toks = (cl->tokens + *diff)) >= hysteresis)
return HTB_CAN_SEND;
*diff = -toks;
@@ -1323,6 +1317,7 @@ static int htb_dump_class(struct Qdisc *
unsigned char *b = skb->tail;
struct rtattr *rta;
struct tc_htb_opt opt;
+ struct tc_htb_hopt hopt;
HTB_DBG(0,1,"htb_dump_class handle=%X clid=%X\n",sch->handle,cl->classid);
@@ -1342,6 +1337,8 @@ static int htb_dump_class(struct Qdisc *
opt.quantum = cl->un.leaf.quantum; opt.prio = cl->un.leaf.prio;
opt.level = cl->level;
RTA_PUT(skb, TCA_HTB_PARMS, sizeof(opt), &opt);
+ hopt.nohyst = cl->nohyst;
+ RTA_PUT(skb, TCA_HTB_NOHYST, sizeof(hopt), &hopt);
rta->rta_len = skb->tail - b;
HTB_QUNLOCK(sch);
return skb->len;
@@ -1527,11 +1524,12 @@ static int htb_change_class(struct Qdisc
struct htb_class *cl = (struct htb_class*)*arg,*parent;
struct rtattr *opt = tca[TCA_OPTIONS-1];
struct qdisc_rate_table *rtab = NULL, *ctab = NULL;
- struct rtattr *tb[TCA_HTB_RTAB];
+ struct rtattr *tb[TCA_HTB_MAX];
struct tc_htb_opt *hopt;
+ struct tc_htb_hopt *uhopt;
/* extract all subattrs from opt attr */
- if (!opt || rtattr_parse_nested(tb, TCA_HTB_RTAB, opt) ||
+ if (!opt || rtattr_parse_nested(tb, TCA_HTB_MAX, opt) ||
tb[TCA_HTB_PARMS-1] == NULL ||
RTA_PAYLOAD(tb[TCA_HTB_PARMS-1]) < sizeof(*hopt))
goto failure;
@@ -1544,6 +1542,10 @@ static int htb_change_class(struct Qdisc
ctab = qdisc_get_rtab(&hopt->ceil, tb[TCA_HTB_CTAB-1]);
if (!rtab || !ctab) goto failure;
+ uhopt = RTA_DATA(tb[TCA_HTB_NOHYST-1]);
+ if (uhopt != NULL && RTA_PAYLOAD(tb[TCA_HTB_NOHYST-1]) < sizeof(*uhopt))
+ goto failure;
+
if (!cl) { /* new class */
struct Qdisc *new_q;
/* check for valid classid */
@@ -1636,6 +1638,7 @@ static int htb_change_class(struct Qdisc
cl->cbuffer = hopt->cbuffer;
if (cl->rate) qdisc_put_rtab(cl->rate); cl->rate = rtab;
if (cl->ceil) qdisc_put_rtab(cl->ceil); cl->ceil = ctab;
+ if (uhopt) cl->nohyst = uhopt->nohyst;
sch_tree_unlock(sch);
*arg = (unsigned long)cl;
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 0/2] Runtime configuration of HTB's HYSTERESIS option
From: Russell Stuart @ 2006-06-15 9:00 UTC (permalink / raw)
To: Jamal Hadi Salim, Stephen Hemminger, Martin Devera, netdev, lartc
Cc: Jesper Dangaard Brouer
The HTB qdisc has a compile time option, HTB_HYSTERESIS,
that trades accuracy of traffic classification for CPU
time. These patches change hysteresis to be a runtime
option under the control of "tc".
The effects of HYSTERESIS on HTB's accuracy are significant
(see chapter 7, section 7.3.1, pp 69-70 in Jesper Brouer's
thesis: http://www.adsl-optimizer.dk/thesis/ ), whereas
HTB's CPU usage on modern machines using broadband links
is minimal. Currently HYSTERESIS is on by default, and
requires a kernel re-compile to change. Altering it to
be a runtime option will make life easier for the bulk of
its users.
Further documentation on the patch and its usage can be
found here:
http://www.stuart.id.au/russell/files/tc/tc-atm
This is a combined effort of Jesper Brouer and Russell
Stuart, to get these patches into the upstream kernel.
Let the discussion start about what we need to change to
get this upstream?
We see this as a feature enhancement, as such hope that
it can be queued in davem's net-2.6.18.git tree.
--
Regards
Russell Stuart and Jesper Brouer
^ permalink raw reply
* Fresh stuff Every man wants it
From: Ahmed @ 2006-06-15 8:30 UTC (permalink / raw)
To: netdev
Hi,
Rock hard manhood, multiple explosions and several times more semen volume
Get a several month supply of everything you need – in seconds
Unique offers on most recognized and famous brands on Earth.
Just take a look: http://www.lutetiaaj.com
The quality is realt high and the prices are the cheapest on the market!
^ permalink raw reply
* New’n’hot I am sure it was
From: Noah @ 2006-06-15 8:16 UTC (permalink / raw)
To: newbie-owner
Good day Bro,
Masculine performance has never been so easy to increase with these products
Don’t hesitate and you will love the lowest possible pricing and the fastest possible shipment
These brands keep thousands and thousands of their customers pleased worldwide
Take a look: http://www.kissyii.com
We offer reliable service and 5 years expirience on the marcket!
^ permalink raw reply
* Re: [patch] ipv4: fix lock usage in udp_ioctl
From: Heiko Carstens @ 2006-06-15 6:55 UTC (permalink / raw)
To: Ingo Molnar
Cc: Herbert Xu, davem, jgarzik, akpm, linux-kernel, netdev, fpavlic
In-Reply-To: <20060615052806.GA19803@elte.hu>
On Thu, Jun 15, 2006 at 08:28:07AM +0200, Ingo Molnar wrote:
>
> * Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> > This is bogus. These two locks belong to two different queues and
> > they never intersect.
>
> yeah - qeth does its own skb-queue management here, and it's done in an
> irq-safe manner.
>
> Heiko, in qeth_main.c, could you do something like:
>
> + static struct lockdep_type_key qdio_out_skb_queue_key;
>
> ...
> skb_queue_head_init(&card->qdio.out_qs[i]->bufs[j].
> skb_list);
> + lockdep_reinit_key(&card->qdio.out_qs[i]->bufs[j].skb_list,
> &qdio_out_skb_queue_key)
How about the patch below? The warning goes away and I assume "tmp_list" needs
lockdep_reinit_key too, since it should have the same locking rules as the
rest of qeth's skb-queue management.
From: Heiko Carstens <heiko.carstens@de.ibm.com>
Avoid false positive illegal lock usage message in qeth driver.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
---
drivers/s390/net/qeth_main.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/s390/net/qeth_main.c 2006-06-15 08:46:26.000000000 +0200
+++ b/drivers/s390/net/qeth_main.c 2006-06-15 08:29:58.000000000 +0200
@@ -85,6 +85,8 @@ static debug_info_t *qeth_dbf_qerr = NUL
DEFINE_PER_CPU(char[256], qeth_dbf_txt_buf);
+static struct lockdep_type_key qdio_out_skb_queue_key;
+
/**
* some more definitions and declarations
*/
@@ -3230,6 +3232,9 @@ qeth_alloc_qdio_buffers(struct qeth_card
&card->qdio.out_qs[i]->qdio_bufs[j];
skb_queue_head_init(&card->qdio.out_qs[i]->bufs[j].
skb_list);
+ lockdep_reinit_key(
+ &card->qdio.out_qs[i]->bufs[j].skb_list.lock,
+ &qdio_out_skb_queue_key);
INIT_LIST_HEAD(&card->qdio.out_qs[i]->bufs[j].ctx_list);
}
}
@@ -5273,6 +5278,7 @@ qeth_free_vlan_buffer(struct qeth_card *
struct sk_buff_head tmp_list;
skb_queue_head_init(&tmp_list);
+ lockdep_reinit_key(&tmp_list.lock, &qdio_out_skb_queue_key);
for(i = 0; i < QETH_MAX_BUFFER_ELEMENTS(card); ++i){
while ((skb = skb_dequeue(&buf->skb_list))){
if (vlan_tx_tag_present(skb) &&
^ permalink raw reply
* Re: [PATCH 2.6.17-rc6] Remove Prism II support from Orinoco
From: Faidon Liambotis @ 2006-06-15 5:15 UTC (permalink / raw)
To: Pavel Roskin; +Cc: John W. Linville, Dave Jones, netdev, hermes
In-Reply-To: <1150346713.26487.24.camel@dv>
Hi,
Pavel Roskin wrote:
> The patch in question was never submitted to the orinoco mailing list.
> I believe any such changes should be discussed by people using the
> driver and participating in its development. It's not some minor change
> or API update.
I'm sorry for not submitting/CCing this to the orinoco mailing list, I
should have.
> I'm ready to consider disabling some ID's conditionally, primarily for
> systems that cannot use udev. But it's far from the top of my TODO
> list. And I'm not sure it would actually help users of desktop
> distributions.
Well, that would be very nice, thanks!
But do you think that it will be enough? I mean, orinoco_{pci,plx,tdm}
exist only to support Prism2 chipsets.
HostAP a rather big and complete driver for Prism2/2.5/3.0 chipsets;
we're going to have another one based on the dscape stack too.
Do you think that there's a point on having the orinoco driver
supporting this chipset any more?
I don't mean to disrespect your work -- orinoco has served us for quite
a few years, but HostAP seems like a better alternative for these cards.
Please don't get offended by this -- I'm sure you've spent quite some
time on the particular code.
Regarding the disabling of IDs, I could prepare a patch for orinoco_cs
that would disable Prism2 support via a configuration option. Would that
be helpful/acceptable?
Best regards,
Faidon
^ permalink raw reply
* Re: [patch] ipv4: fix lock usage in udp_ioctl
From: Ingo Molnar @ 2006-06-15 5:28 UTC (permalink / raw)
To: Herbert Xu
Cc: Heiko Carstens, davem, jgarzik, akpm, linux-kernel, netdev,
fpavlic
In-Reply-To: <E1FqeXX-0008OE-00@gondolin.me.apana.org.au>
* Herbert Xu <herbert@gondor.apana.org.au> wrote:
> This is bogus. These two locks belong to two different queues and
> they never intersect.
yeah - qeth does its own skb-queue management here, and it's done in an
irq-safe manner.
Heiko, in qeth_main.c, could you do something like:
+ static struct lockdep_type_key qdio_out_skb_queue_key;
...
skb_queue_head_init(&card->qdio.out_qs[i]->bufs[j].
skb_list);
+ lockdep_reinit_key(&card->qdio.out_qs[i]->bufs[j].skb_list,
&qdio_out_skb_queue_key)
Ingo
^ permalink raw reply
* Re: [PATCH 2.6.17-rc6] Remove Prism II support from Orinoco
From: Pavel Roskin @ 2006-06-15 4:52 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: John W. Linville, Faidon Liambotis, Dave Jones, netdev, hermes
In-Reply-To: <4807377b0606121710j5be6ce0fhac71b69bf4dce2c2@mail.gmail.com>
On Mon, 2006-06-12 at 17:10 -0700, Jesse Brandeburg wrote:
> my problem is that for my prism 2 adapter both drivers are loaded at
> which point neither of them works. I'm running FC5, and i have to
> keep removing the orinoco*.ko files to keep them from loading, so I'm
> all for this patch.
I believe the right solution would be to do it in userspace. The kernel
should not be making decisions which driver is _better_ for the device.
I'm yet to see any serious arguments why the kernel should be doing it.
As for non-working driver, this should be reported with sufficient
details. I haven't seen any detailed reports of this problem.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH 2.6.17-rc6] Remove Prism II support from Orinoco
From: Pavel Roskin @ 2006-06-15 4:45 UTC (permalink / raw)
To: John W. Linville; +Cc: Faidon Liambotis, Dave Jones, netdev, hermes
In-Reply-To: <20060612152434.GA14851@tuxdriver.com>
Hello, John!
On Mon, 2006-06-12 at 11:24 -0400, John W. Linville wrote:
> On Mon, Jun 12, 2006 at 01:49:54AM +0300, Faidon Liambotis wrote:
>
> > Having two drivers supporting the same set of hardware seems pretty
> > pointless to me. Plus, it confuses hotplugging/automatic detection.
>
> This subject comes-up from time to time. In fact, I'm pretty sure
> it came-up very recently w.r.t. orinoco and hostap.
>
> The consensus seems to be that drivers should have IDs for all devices
> they support, even if that means that some devices are supported by
> multiple drivers. This leaves the choice of which driver to use in
> the hands of the user and/or distro.
>
> If the Orinoco guys want this patch, I'll consider it. Otherwise,
> I'm not inclined to take it.
I really appreciate your position in this regard.
The patch in question was never submitted to the orinoco mailing list.
I believe any such changes should be discussed by people using the
driver and participating in its development. It's not some minor change
or API update.
I'm ready to consider disabling some ID's conditionally, primarily for
systems that cannot use udev. But it's far from the top of my TODO
list. And I'm not sure it would actually help users of desktop
distributions.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [patch] e100 statistic value "rx_bytes" error
From: Auke Kok @ 2006-06-15 4:35 UTC (permalink / raw)
To: Wei Dong; +Cc: netdev, Jesse Brandeburg, Ronciak, John, Auke Kok, Kok, Auke
In-Reply-To: <1150345027.3008.10.camel@L-tech>
Wei Dong wrote:
> Hi All:
> When I test linux kernel(2.6.9-16), I found that maybe there is a bug
> in e100 driver. See function e100_rx_indicate() at line 1847:
> nic->net_stats.rx_bytes += actual_size;
> Here, actual_size is the actual size of an ethernent frame sans FCS.And
> the e100 driver gets it from skb. Because "rx_bytes" is a statistc value
> for a NIC, I think rx_bytes should include the FCS(4 bytes).
> The following is the patch for the function in e100.c
This is definately not an issue, and I'm not for changing this: It always was
like this in the first place. It's done for many drivers like this anyway,
mostly those without real hardware counters do it this way anyway (I count
half a dozen or so on first glance).
On top of that we would be changing statistics numbers after x years of e100
driver. I'm sure everyone doing real performance work will frown upon this.
Next it's unlikely that every driver (or worse, every nic in hardware)
accounts for FCS in the rx_bytes count. It really wouldn't surprise me if a
driver (or chip) got this wrong here or there.
Bottom line is that for e100, it's well known and easily seeable that e100 is
counting skb sizes. That's consistent and I think we should keep it that way.
Auke
PS please cc the driver maintainers when you post patches to a specific driver.
> diff -ruN old/drivers/net/e100.c new/drivers/net/e100.c
> --- old/drivers/net/e100.c 2006-03-20 13:53:29.000000000 +0800
> +++ new/drivers/net/e100.c 2006-06-15 11:16:04.000000000 +0800
> @@ -1844,7 +1844,8 @@
> dev_kfree_skb_any(skb);
> } else {
> nic->net_stats.rx_packets++;
> - nic->net_stats.rx_bytes += actual_size;
> + /* Don't forget FCS */
> + nic->net_stats.rx_bytes += actual_size + 4;
> nic->netdev->last_rx = jiffies;
> netif_receive_skb(skb);
> if(work_done)
>
> BR.
> Weidong
>
> Signed-off-by: Weidong <weid@nanjing-fnst.com>
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [patch] e100 statistic value "rx_bytes" error
From: Wei Dong @ 2006-06-15 4:17 UTC (permalink / raw)
To: netdev; +Cc: davem
Hi All:
When I test linux kernel(2.6.9-16), I found that maybe there is a bug
in e100 driver. See function e100_rx_indicate() at line 1847:
nic->net_stats.rx_bytes += actual_size;
Here, actual_size is the actual size of an ethernent frame sans FCS.And
the e100 driver gets it from skb. Because "rx_bytes" is a statistc value
for a NIC, I think rx_bytes should include the FCS(4 bytes).
The following is the patch for the function in e100.c
diff -ruN old/drivers/net/e100.c new/drivers/net/e100.c
--- old/drivers/net/e100.c 2006-03-20 13:53:29.000000000 +0800
+++ new/drivers/net/e100.c 2006-06-15 11:16:04.000000000 +0800
@@ -1844,7 +1844,8 @@
dev_kfree_skb_any(skb);
} else {
nic->net_stats.rx_packets++;
- nic->net_stats.rx_bytes += actual_size;
+ /* Don't forget FCS */
+ nic->net_stats.rx_bytes += actual_size + 4;
nic->netdev->last_rx = jiffies;
netif_receive_skb(skb);
if(work_done)
BR.
Weidong
Signed-off-by: Weidong <weid@nanjing-fnst.com>
^ permalink raw reply
* Re: [PATCH] Make in-kernel hostap less annoying
From: Jouni Malinen @ 2006-06-15 3:41 UTC (permalink / raw)
To: Kyle McMartin; +Cc: netdev
In-Reply-To: <20060612191302.GD32443@skunkworks.cabal.ca>
On Mon, Jun 12, 2006 at 03:13:02PM -0400, Kyle McMartin wrote:
> Most user don't want their kern.log/dmesg filled with
> debugging gibberish, and could turn it on if prompted.
>
> ( Example:
> wifi0: TXEXC - status=0x0004 ([Discon]) tx_control=000c
> retry_count=0 tx_rate=0 fc=0x0108 (Data::0 ToDS)
> A1=00:0f:66:43:d7:0a A2=00:05:3c:06:63:01 A3=33:33:00:00:00:16
> A4=00:00:00:00:00:00 )
I agree with removing these by default. However, I would prefer to do
this in more selective manor than disabling all debugging information at
build time. This would probably involve going through all debug messages
using this mechanism and selecting whether they are reasonable to enable
by default or not and ideally doing this as a run-time option.
> Also make hostap default to managed mode, instead of master mode, which
> has bitten a few users expecting it to behave like the orinoco driver
> it is replacing.
NAK. Host AP has been configured to use master mode by default for the
past six years and that is what most users would expect it to continue
to do. I do understand that this default differs from all drivers that
do not support AP mode, but I think it is too late to change this now.
The default could change once Host AP gets replaced with
net/d80211-based implementation for Prism2/2.5/3, but I would not change
this for Host AP driver.
> Two minor things I've been carrying around in my personal tree
> for quite some time. (This is only relevant to the in-kernel driver,
> I see no reason to change the out-of-tree driver.)
That would be even more confusing for the default mode.. I believe that
both versions should continue to use Master mode as the default unless
overridden by user.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Your health, oil shark
From: Jeannie Dailey @ 2006-06-15 2:52 UTC (permalink / raw)
To: netdev
Even if you have no erectin problems SOFT CIAzLIS
would help you to make BETTER SE X MORE OFTEN!
and to bring unimagnable plesure to her.
Just disolve half a pil under your tongue
and get ready for action in 15 minutes.
The tests showed that the majority of men
after taking this medic ation were able to have
PERFECT ER ECTI ON during 36 hours!
VISIT US, AND GET OUR SPECIAL 70% DISC OUNT OFER!
http://olgiks.livingpaw.com/?76593014
==========
thing or two about flying!
We came out into the sun and stopped by the boot. Tender reached out for it.
that? What does it feel like? How far can you go?"
could see how pleased he was. His eyes lit up and there was color in his
answer "Woman" is disallowed as too obvious a rejoinder.)
"That's all I wanted cleared up. You're Free to go.
Fletcher Seagull, who loved aerobatics like no one else, conquered
store for me here?"
^ permalink raw reply
* Re: [PATCH 2/2] NET: Accurate packet scheduling for ATM/ADSL (userspace)
From: Russell Stuart @ 2006-06-15 0:47 UTC (permalink / raw)
To: Alan Cox; +Cc: Stephen Hemminger, Jamal Hadi Salim, netdev, linux-kernel
In-Reply-To: <1150282625.3490.23.camel@localhost.localdomain>
On Wed, 2006-06-14 at 11:57 +0100, Alan Cox wrote:
> The other problem I see with this code is it is very tightly tied to ATM
> cell sizes, not to solving the generic question of packetisation.
Others have made this point also. I can't speak for Jesper,
but I did consider making it generic. The issue was that
doing so would add more code, but I don't personally know
of any real world situation that would use the generic
solution. I didn't fancy the thought of arguing on these
lists for code that no one would actually use.
If someone could put up their hand and say "Hey, I need
this," then expanding the patch to accommodate them would
be a pleasure. I like generic code too.
Russell
^ permalink raw reply
* Re: [PATCH 1/2] e1000: fix netpoll with NAPI
From: Mitch Williams @ 2006-06-14 23:44 UTC (permalink / raw)
To: Neil Horman
Cc: Williams, Mitch A, Jeff Moyer, Kok, Auke-jan H, Matt Mackall,
Garzik, Jeff, netdev, Brandeburg, Jesse, Kok, Auke
In-Reply-To: <20060614204158.GA3967@hmsreliant.homelinux.net>
On Wed, 14 Jun 2006, Neil Horman wrote:
> Hey, as promised, I've done some rudimentary performance benchmarking on various
> ways that we have talked about to solve this problem. As I previously mentioned
We see the same results here, Neil. However, we've got a much less
invasive patch undergoing internal review, and which we will post to
netdev once everybody gets happy with it. Basically, we just do our NAPI
scheduling on the "real" netdev structure instead of our polling netdev,
in the case where we only have one RX queue. Since this is the case for
all our currently-shipping parts under Linux, netpoll works again across
the board. It's a short-term fix because we do want to support multiple
queues going forward, but for now we need to get everybody working.
One of our engineers (on the I/O AT team) has been tasked with modifying
the Linux kernel to properly support multiple hardware queues (both TX and
RX). We'll make sure that he looks at the netpoll interface as part of
that process.
Stay tuned for our impending patch.
-Mitch
^ permalink raw reply
* Re: [patch] ipv4: fix lock usage in udp_ioctl
From: Herbert Xu @ 2006-06-14 23:12 UTC (permalink / raw)
To: Heiko Carstens; +Cc: davem, jgarzik, akpm, linux-kernel, netdev, mingo, fpavlic
In-Reply-To: <20060614194305.GB10391@osiris.ibm.com>
Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
>
> As reported by the lock validator:
>
> ============================
> [ BUG: illegal lock usage! ]
> ----------------------------
> illegal {in-hardirq-W} -> {hardirq-on-W} usage.
> syslogd/739 [HC0[0]:SC0[1]:HE1:SE0] takes:
> (&list->lock){++..}, at: [<002e36d6>] udp_ioctl+0x96/0x100
> {in-hardirq-W} state was registered at:
> [<00062128>] lock_acquire+0x9c/0xc0
> [<0036209e>] _spin_lock_irqsave+0x66/0x84
> [<002912ce>] skb_dequeue+0x32/0xb0
> [<00263160>] qeth_qdio_output_handler+0x3e8/0xf8c
> [<00219fdc>] tiqdio_thinint_handler+0xde0/0x2234
> [<0020448c>] do_adapter_IO+0x5c/0xa8
> [<0020842c>] do_IRQ+0x13c/0x18c
> [<000208a2>] io_no_vtime+0x16/0x1c
> [<0001978c>] cpu_idle+0x1d0/0x20c
This is bogus. These two locks belong to two different queues and they
never intersect.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: tcp_slow_start_after_idle
From: David Miller @ 2006-06-14 23:06 UTC (permalink / raw)
To: rick.jones2; +Cc: netdev, zach.brown, jheffner
In-Reply-To: <44903D82.40007@hp.com>
From: Rick Jones <rick.jones2@hp.com>
Date: Wed, 14 Jun 2006 09:46:58 -0700
> Also, does the congestion window "time out" or does it decay?
The modification made to the cwnd is indeed a decay function,
but the event is a time out, and it is also termed a restart
in other writings and contexts.
I think it's all the same. :)
> > +/* By default, RFC2861 behavior. */
> > +int sysctl_tcp_slow_start_after_idle = 1;
> > +
>
> Is this a candidate for "readmostly?"
All the networking sysctls are, we should do a sweep over them at some
point.
Thanks for reminding me.
^ permalink raw reply
* Re: tcp_slow_start_after_idle
From: David Miller @ 2006-06-14 22:30 UTC (permalink / raw)
To: zach.brown; +Cc: netdev, jheffner
In-Reply-To: <449042E0.4020409@oracle.com>
From: Zach Brown <zach.brown@oracle.com>
Date: Wed, 14 Jun 2006 10:09:52 -0700
> Nice, thanks for the heads-up. I'll pass the notice on to the guys who
> were asking about this in that thread.
Which Wall Street brokerage firm was it? :-)
That's basically who wants this stuff, people doing financial
transactions. They seem to open up a connection, and just blast out
data periodically (with frequency > RTO, which is the whole problem)
and they want good latency results from that.
^ permalink raw reply
* Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late
From: Grant Grundler @ 2006-06-14 22:30 UTC (permalink / raw)
To: Francois Romieu
Cc: Grant Grundler, Jeff Garzik, Valerie Henson, Andrew Morton,
netdev
In-Reply-To: <20060614204720.GA17887@electric-eye.fr.zoreil.com>
On Wed, Jun 14, 2006 at 10:47:20PM +0200, Francois Romieu wrote:
> Grant Grundler <grundler@parisc-linux.org> :
> [...]
> > I'm not keen on adding more code to tulip_interrupt() routine
> > for something that rarely happens (compared to IRQs) and is handled
> > outside the interrupt routine. I'm pretty sure stopping interrupts
> > before stopping DMA is sufficient.
> > Can you show an example where it doesn't work?
>
> Shared irq.
>
> The device has not quiesced, the kernel stop listening to it and the
> neighbor device receives a late interruption from the network device.
I thought we've worked through that already:
http://www.spinics.net/lists/netdev/msg05902.html
Patch v3 takes care of that problem.
The first step in the sequence is to mask IRQs on the tulip.
The "neighbor" device sharing the IRQ will not see any interrupts from
the tulip after that.
thanks,
grant
^ 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