* Re: [PATCH] sky2: rx hash offload
From: David Miller @ 2010-04-08 5:04 UTC (permalink / raw)
To: eric.dumazet; +Cc: shemminger, netdev, therbert
In-Reply-To: <1270557210.2081.8.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 06 Apr 2010 14:33:30 +0200
> Le lundi 05 avril 2010 à 08:48 -0700, Stephen Hemminger a écrit :
>> Marvell Yukon 2 hardware supports hardware receive hash calculation.
>> Now that Receive Packet Steering is available, add support
>> to enable it.
>>
>> Note: still experimental, tested on only a few variants.
>> No performance testing has been done.
>>
>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>>
>> ---
>> drivers/net/sky2.c | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++--
>> drivers/net/sky2.h | 23 ++++++++++++++++
>> 2 files changed, 96 insertions(+), 2 deletions(-)
>
> I am wondering if introducing hardware computed rxhash wouldnt force us
> to clear rxhash in several paths (tunneling...), so that we perform a
> software recompute after decapsulation, to enable RFS
>
> Not mandatory but recommended I would say...
nf_reset() and clearing things like this new rxhash thing
should be encapsulated into a helper function that we can
stick into the tunnel drivers and such.
^ permalink raw reply
* Re: tulip_stop_rxtx() failed (CSR5 0xf0260000 CSR6 0xb3862002) on DEC Alpha Personal Workstation 433au
From: David Miller @ 2010-04-08 5:01 UTC (permalink / raw)
To: glaubitz; +Cc: joe, grundler, kyle, netdev, linux-kernel
In-Reply-To: <20100407134228.GC31252@physik.fu-berlin.de>
From: Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date: Wed, 7 Apr 2010 15:42:28 +0200
> Hi,
>
> On Mon, Apr 05, 2010 at 10:36:22AM -0700, Joe Perches wrote:
>> On Mon, 2010-04-05 at 19:13 +0200, Adrian Glaubitz wrote:
>> > Hi guys,
>> >
>> > I installed Debian unstable on an old digital workstation "DEC Digital
>> > Personal Workstation 433au" (Miata) which has an on-board tulip
>> > network controller. I'm not really using that network controller but
>> > an off-board intel e1000 controller. However, I found that the tulip
>> > driver produces a lot of noise in the message log, the following
>> > message is repated periodically and spams the whole message log:
>> >
>> > 0000:00:03.0: tulip_stop_rxtx() failed (CSR5 0xf0260000 CSR6 0xb3862002)
>> >
>> > Do you think this is related to the fact that no cable is connected to
>> > the network controller?
>>
>> Probably something is trying periodically to open the device.
>> Maybe this helps reduce the message log noise:
>>
>> Signed-off-by: Joe Perches <joe@perches.com>
>
> Acked-by: Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
>
> Patch works perfectly. Now the message log looks pretty normal.
This doesn't fix the problem, it just makes the message get
emitted in a rate limited manner.
I'm not going to apply this, we need to figure out what's causing
this problem instead of merely papering over it.
Thanks.
^ permalink raw reply
* Re: [PATCH v3 0/4] xfrm: add x86 CONFIG_COMPAT support
From: David Miller @ 2010-04-08 5:00 UTC (permalink / raw)
To: fw; +Cc: netdev, johannes
In-Reply-To: <20100407133528.GD22518@Chamillionaire.breakpoint.cc>
From: Florian Westphal <fw@strlen.de>
Date: Wed, 7 Apr 2010 15:35:28 +0200
> But whats really bothering me is the number of sys_compat_* functions
> needed to make all possibilities work;. e.g. to make (unmodified)
> strongwan work, sys_compat_write and sys_compat_sendto are needed.
Thank the BSD socket API designer(s) for adding N different ways to
essentially say the same thing instead of just having sendmsg/recvmsg
and saying "if you don't want to specify X, just pass in NULL" or
whatever. :-)
Because that's all that sendto() is, it's a sendmsg() without
an arg or two. But in the end the kernel internally has to
come up with pretend arguments for all of this stuff anyways
since the protocols end up having to accomodate all of
the sendmsg() cases anyways.
And it's not all that bad, we just need the numerous compat entry
points to set the compat flag bit, the rest of the implementation is
going to be %100 shared code.
And once it's there, we can use it for other similar cases, not
just xfrm netlink.
^ permalink raw reply
* Re: hackbench regression due to commit 9dfc6e68bfe6e
From: Eric Dumazet @ 2010-04-08 4:59 UTC (permalink / raw)
To: Zhang, Yanmin
Cc: Christoph Lameter, Pekka Enberg, netdev, Tejun Heo, alex.shi,
linux-kernel@vger.kernel.org, Ma, Ling, Chen, Tim C,
Andrew Morton
In-Reply-To: <1270688747.2078.383.camel@ymzhang.sh.intel.com>
Le jeudi 08 avril 2010 à 09:05 +0800, Zhang, Yanmin a écrit :
> > Do we have a user program to check actual L1 cache size of a machine ?
> If there is no, it's easy to write it as kernel exports the cache stat by
> /sys/devices/system/cpu/cpuXXX/cache/indexXXX/
Yes, this is what advertizes my L1 cache having 64bytes lines, but I
would like to check that in practice, this is not 128bytes...
./index0/type:Data
./index0/level:1
./index0/coherency_line_size:64
./index0/physical_line_partition:1
./index0/ways_of_associativity:8
./index0/number_of_sets:64
./index0/size:32K
./index0/shared_cpu_map:00000101
./index0/shared_cpu_list:0,8
./index1/type:Instruction
./index1/level:1
./index1/coherency_line_size:64
./index1/physical_line_partition:1
./index1/ways_of_associativity:4
./index1/number_of_sets:128
./index1/size:32K
./index1/shared_cpu_map:00000101
./index1/shared_cpu_list:0,8
^ permalink raw reply
* Re: [PATCH 1/1] - fix ethtool coding style errors and warnings
From: David Miller @ 2010-04-08 4:55 UTC (permalink / raw)
To: chavey; +Cc: netdev, therbert
In-Reply-To: <pvmaateq2uv.fsf@chavey.mtv.corp.google.com>
From: chavey@google.com
Date: Wed, 07 Apr 2010 16:06:48 -0700
>>From dcdd5d730a5a0d72c11e5010c65ed3b827fc1b85 Mon Sep 17 00:00:00 2001
> From: chavey <chavey@google.com>
> Date: Wed, 7 Apr 2010 15:53:31 -0700
>
> Fix coding style errors and warnings output while running checkpatch.pl
> on the files net/core/ethtool.c and include/linux/ethtool.h
Seems like pointless masterbation to me, but whatever,
applied.
> Signed-off-by: chavey <chavey@google.com>
Can I trouble you to put your real full name in at least your
signoffs instead of just a copy of your email address user
name?
Thanks.
^ permalink raw reply
* Re: [PATCH] macb: allow reception of large (>1518 bytes) frames
From: David Miller @ 2010-04-08 4:53 UTC (permalink / raw)
To: peter.korsgaard; +Cc: haavard.skinnemoen, netdev, linux-kernel
In-Reply-To: <1270652389-5364-1-git-send-email-peter.korsgaard@barco.com>
From: Peter Korsgaard <peter.korsgaard@barco.com>
Date: Wed, 7 Apr 2010 16:59:49 +0200
> Enable BIG bit in the network configuration register, so the MAC doesn't
> reject big frames (E.G. when vlans are used).
>
> Signed-off-by: Peter Korsgaard <peter.korsgaard@barco.com>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH] corrected documentation for hardware time stamping
From: David Miller @ 2010-04-08 4:53 UTC (permalink / raw)
To: loschmidt, Patrick.Loschmidt; +Cc: netdev, patrick.ohly
In-Reply-To: <4BBC6944.2090102@OEAW.ac.at>
From: Patrick Loschmidt <Patrick.Loschmidt@OEAW.ac.at>
Date: Wed, 07 Apr 2010 13:15:16 +0200
> From: Patrick Loschmidt <Patrick.Loschmidt@oeaw.ac.at>
>
> The current documentation for hardware time stamping does not correctly specify the available kernel
> functions since the implementation was changed later on.
>
> Signed-off-by: Patrick Loschmidt <Patrick.Loschmidt@oeaw.ac.at>
Applied thanks.
> --- Documentation/networking/timestamping.txt.orig 2010-04-07 12:52:47.000000000 +0200
> +++ Documentation/networking/timestamping.txt 2010-04-07 11:43:57.000000000 +0200
Please "-p1" base your patches in the future.
> /* PTP v1, UDP, any kind of event packet */
> HWTSTAMP_FILTER_PTP_V1_L4_EVENT,
> -
> - ...
> +
That line has extraneous trailing whitespace which I needed
to fix up when applying your patch.
Please attend to these details properly in future patch
submissions, as it will save me a lot of time.
Thanks.
^ permalink raw reply
* Re: [patch] stmmac: use resource_size()
From: David Miller @ 2010-04-08 4:50 UTC (permalink / raw)
To: error27; +Cc: peppe.cavallaro, joe, tj, cl, netdev, kernel-janitors
In-Reply-To: <20100407093546.GF5157@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Wed, 7 Apr 2010 12:35:46 +0300
> Resource size should be calculated as end - start + 1 because we start
> counting at zero. I changed the code to resource_size() to do the
> calculation.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied, thanks Dan.
^ permalink raw reply
* Re: [PATCH] packet: support for TX time stamps on RAW sockets
From: David Miller @ 2010-04-08 4:47 UTC (permalink / raw)
To: richardcochran; +Cc: netdev, patrick.ohly
In-Reply-To: <20100406143030.GA26954@riccoc20.at.omicron.at>
From: Richard Cochran <richardcochran@gmail.com>
Date: Tue, 6 Apr 2010 16:30:30 +0200
> Enable the SO_TIMESTAMPING socket infrastructure for raw packet sockets.
> For lack of a better idea, we have elected to use PACKET_RECV_OUTPUT for
> the control message cmsg_type. This macro currently is not used anywhere
> within the kernel.
>
> Similar support for UDP and CAN sockets was added in commit
> 51f31cabe3ce5345b51e4a4f82138b38c4d5dc91
>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
Why not add some new value, with a well formed name, just to make it
explicit what it's used for?
> + put_cmsg(msg,SOL_PACKET,PACKET_RECV_OUTPUT,sizeof(serr->ee),&serr->ee);
Spaces between arguments, and you'll thus need to break this up into
multiple lines to keep it within 80 columns.
^ permalink raw reply
* Re: re-submit3 [ANNOUNCEMENT] NET: usb: sierra_net.c driver
From: David Miller @ 2010-04-08 4:45 UTC (permalink / raw)
To: epasheva-ywE8TTl5eJHWpu6QEFMNjNBPR1lH4CV8
Cc: dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f,
rfiler-ywE8TTl5eJHWpu6QEFMNjNBPR1lH4CV8,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1270517948.14692.9.camel@Linuxdev4-laptop>
From: Elina Pasheva <epasheva-ywE8TTl5eJHWpu6QEFMNjNBPR1lH4CV8@public.gmane.org>
Date: Mon, 5 Apr 2010 18:39:08 -0700
> Subject: re-submit3 [ANNOUNCEMENT] NET: usb: sierra_net.c driver
> From: Elina Pasheva <epasheva-ywE8TTl5eJHWpu6QEFMNjNBPR1lH4CV8@public.gmane.org>
I want you to tell me exactly how you generated this patch.
It doesn't apply, and I suspect that you tried to fix the excess empty
lines at the end of certain files by editing the patch by hand.
If so, did you test the result?
The patch is corrupted and more importantly git won't accept it.
davem@sunset:~/src/GIT/net-2.6$ git am --signoff re-submit3-ANNOUNCEMENT-NET-usb-sierra_net.c-driver.patch
Applying: re-submit3 [ANNOUNCEMENT] NET: usb: sierra_net.c driver
/home/davem/src/GIT/net-2.6/.git/rebase-apply/patch:36: new blank line at EOF.
+
error: drivers/net/usb/sierra_net.c: does not exist in index
Patch failed at 0001 re-submit3 [ANNOUNCEMENT] NET: usb: sierra_net.c driver
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] rfs: Receive Flow Steering
From: David Miller @ 2010-04-08 4:40 UTC (permalink / raw)
To: therbert; +Cc: davem, netdev, eric.dumazet
In-Reply-To: <alpine.DEB.1.00.1004052248390.29212@pokey.mtv.corp.google.com>
From: Tom Herbert <therbert@google.com>
Date: Mon, 5 Apr 2010 22:56:50 -0700 (PDT)
> @@ -2342,6 +2387,10 @@ static int enqueue_to_backlog(struct sk_buff *skb, int cpu)
> if (queue->input_pkt_queue.qlen) {
> enqueue:
> __skb_queue_tail(&queue->input_pkt_queue, skb);
> +#ifdef CONFIG_RPS
> + *qtail = queue->input_queue_head +
> + queue->input_pkt_queue.qlen;
> +#endif
> rps_unlock(queue);
> local_irq_restore(flags);
> return NET_RX_SUCCESS;
...
> @@ -2801,6 +2864,9 @@ static void flush_backlog(void *arg)
> if (skb->dev == dev) {
> __skb_unlink(skb, &queue->input_pkt_queue);
> kfree_skb(skb);
> +#ifdef CONFIG_RPS
> + queue->input_queue_head++;
> +#endif
> }
> rps_unlock(queue);
> }
Please abstract these behind inline functions that live in
some header file, so we don't need to continually pepper
dev.c with countless ifdefs.
If you fix this and the kernel command line --> sysctl thing
Eric pointed out, I think I can apply this to net-next-2.6
Thanks.
^ permalink raw reply
* Re: patch to improve x.25 throughput negotiation
From: David Miller @ 2010-04-08 4:33 UTC (permalink / raw)
To: andrew.hendry; +Cc: john, netdev
In-Reply-To: <v2jd45a3acc1004060509u88f32fa1va0c374154806535b@mail.gmail.com>
From: andrew hendry <andrew.hendry@gmail.com>
Date: Tue, 6 Apr 2010 22:09:10 +1000
> I have reproduced a few ways.
> 1. X25_MASK_THROUGHPUT on the x25_subscript_struct, then call
> SIOCX25SSUBSCRIP, then call SIOCX25FACILITIES without setting the
> throughput field. Call connect.
> 2. No subscrip setting, call SIOCX25FACILITIES without setting the
> throughput field. Call connect.
> 3. No subcrip, no facilities ioctl, call connect.
>
> The patch removes the bad facility and makes the router accept the
> call for the above cases.
> I don't currently have a setup to test both direction throughput negotiation.
>
> Tested-by: Andrew Hendry <andrew.hendry@gmail.com>
Patch applied, thanks everyone.
^ permalink raw reply
* Re: Patch to fix kernel bug 15678 - x25 code accesses fields beyond the end of packet.
From: David Miller @ 2010-04-08 4:29 UTC (permalink / raw)
To: john; +Cc: netdev
In-Reply-To: <4BB8C0F1.2090100@Calva.COM>
From: John Hughes <john@Calva.COM>
Date: Sun, 04 Apr 2010 18:40:17 +0200
> From: John Hughes <john@calva.com>
> Subject: Patch to fix bug 15678 - x25 accesses fields beyond end of packet.
>
> Here is a patch to stop X.25 examining fields beyond the end of the packet.
>
> For example, when a simple CALL ACCEPTED was received:
>
> 10 10 0f
>
> x25_parse_facilities was attempting to decode the FACILITIES field, but this
> packet contains no facilities field.
>
> Signed-off-by: John Hughes <john@calva.com>
Applied, thanks John.
^ permalink raw reply
* Re: [PATCH] myri10ge: fix rx_pause in myri10ge_set_pauseparam
From: David Miller @ 2010-04-08 4:26 UTC (permalink / raw)
To: brice; +Cc: netdev, gallatin
In-Reply-To: <4BB8ADE4.5090304@myri.com>
From: Brice Goglin <brice@myri.com>
Date: Sun, 04 Apr 2010 17:19:00 +0200
> Fix rx_pause in myri10ge_set_pauseparam().
>
> Signed-off-by: Brice Goglin <brice@myri.com>
Your patch is tab/whitespace damaged by your email client.
Fix this up and resubmit, thanks.
^ permalink raw reply
* Re: bridge: Fix IGMP3 report parsing
From: David Miller @ 2010-04-08 4:21 UTC (permalink / raw)
To: herbert; +Cc: netdev, banyeer
In-Reply-To: <20100408040709.GA19944@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 8 Apr 2010 12:07:09 +0800
> On Wed, Apr 07, 2010 at 08:52:48PM -0700, David Miller wrote:
>>
>> If pskb_may_pull() actually does anything non-trivial,
>> skb->data will change and you'll be referring to freed
>> up memory.
>>
>> That's probably why you had the grec assignment where
>> you originally had it in the first place :-)
>
> Heh, you're clearly more awake than I was :)
:-)
> bridge: Fix IGMP3 report parsing
>
> The IGMP3 report parsing is looking at the wrong address for
> group records. This patch fixes it.
>
> Reported-by: Banyeer <banyeer@yahoo.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks Herbert.
^ permalink raw reply
* Re: bridge: Fix IGMP3 report parsing
From: Herbert Xu @ 2010-04-08 4:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev, banyeer
In-Reply-To: <20100407.205248.113724360.davem@davemloft.net>
On Wed, Apr 07, 2010 at 08:52:48PM -0700, David Miller wrote:
>
> If pskb_may_pull() actually does anything non-trivial,
> skb->data will change and you'll be referring to freed
> up memory.
>
> That's probably why you had the grec assignment where
> you originally had it in the first place :-)
Heh, you're clearly more awake than I was :)
bridge: Fix IGMP3 report parsing
The IGMP3 report parsing is looking at the wrong address for
group records. This patch fixes it.
Reported-by: Banyeer <banyeer@yahoo.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 6980625..f29ada8 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -723,7 +723,7 @@ static int br_multicast_igmp3_report(struct net_bridge *br,
if (!pskb_may_pull(skb, len))
return -EINVAL;
- grec = (void *)(skb->data + len);
+ grec = (void *)(skb->data + len - sizeof(*grec));
group = grec->grec_mca;
type = grec->grec_type;
Thanks,
--
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 related
* Re: [PATCH] bnx2x: use the dma state API instead of the pci equivalents
From: David Miller @ 2010-04-08 4:06 UTC (permalink / raw)
To: eilong; +Cc: fujita.tomonori, netdev, vladz
In-Reply-To: <1270561278.1848.5.camel@lb-tlvb-eilong.il.broadcom.com>
From: "Eilon Greenstein" <eilong@broadcom.com>
Date: Tue, 6 Apr 2010 16:41:18 +0300
> On Tue, 2010-04-06 at 00:39 -0700, Vladislav Zolotarov wrote:
>> Thanks, Fujita.
>>
>> The patch looks fine. I'll run some regression tests on the patched driver to check that things still work and if it's ok we will ack it shortly.
>>
>> vlad
>>
>>
>
>> > =
>> > From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
>> > Subject: [PATCH] bnx2x: use the DMA API instead of the pci equivalents
>> >
>> > The DMA API is preferred.
>> >
>> > Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> Vlad's testing with this patch were finished successfully.
>
> Thanks Fujita!
> Acked-by: Vladislav Zolotarov <vladz@broadcom.com>
> Acked-by: Eilon Greenstein <eilong@broadcom.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] bnx2: use the dma state API instead of the pci equivalents
From: David Miller @ 2010-04-08 4:05 UTC (permalink / raw)
To: fujita.tomonori; +Cc: netdev, mchan
In-Reply-To: <20100402115025A.fujita.tomonori@lab.ntt.co.jp>
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Date: Fri, 2 Apr 2010 11:56:57 +0900
> The DMA API is preferred.
>
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Applied.
^ permalink raw reply
* Re: [PATCHv2] virtio-net: move sg off stack
From: David Miller @ 2010-04-08 4:01 UTC (permalink / raw)
To: mst; +Cc: rusty, jpirko, xma, netdev, linux-kernel
In-Reply-To: <20100404130741.GA7500@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Sun, 4 Apr 2010 16:07:41 +0300
> Move sg structure off stack and into virtnet_info structure.
> This helps remove extra sg_init_table calls as well as reduce
> stack usage.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> Tested-by: Michael S. Tsirkin <mst@redhat.com>
Applied to net-next-2.6, thanks Michael.
^ permalink raw reply
* Re: [PATCH 2/2] benet: fix the misusage of zero dma address
From: David Miller @ 2010-04-08 3:59 UTC (permalink / raw)
To: sathyap; +Cc: fujita.tomonori, subbus, sarveshwarb, ajitk, netdev
In-Reply-To: <20100405082202.GB32671@serverengines.com>
From: Sathya Perla <sathyap@serverengines.com>
Date: Mon, 5 Apr 2010 13:52:02 +0530
> On 05/04/10 16:40 +0900, FUJITA Tomonori wrote:
>> > > + wrb->frag_len = 0;
>> > Why does wrb->frag_len need to be reset here?
>> > In the TX path, it is set to the proper value for data wrbs and zero
>> > for dummy and hdr wrbs.
>>
>> I guess that I misunderstood why unmap_tx_frag() checks a dma address.
>> The checking is necessary to avoid calling pci_unamp_* API for dummy
>> hdr wrbs?
> Yes.
>>
>> Anyway, if wrb->frag_len doesn't need to be reset here, the following
>> patch is ok?
> Yes. Thanks.
>
> Acked-by: Sathya Perla <sathyap@serverengines.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 1/2] benet: use the dma state API instead of the pci equivalents
From: David Miller @ 2010-04-08 3:59 UTC (permalink / raw)
To: sathyap; +Cc: fujita.tomonori, subbus, sarveshwarb, ajitk, netdev
In-Reply-To: <20100405090457.GA2541@serverengines.com>
From: Sathya Perla <sathyap@serverengines.com>
Date: Mon, 5 Apr 2010 14:34:57 +0530
> Thanks.
>
> Acked-by: Sathya Perla <sathyap@serverengines.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH] 3c503: Fix IRQ probing
From: David Miller @ 2010-04-08 3:56 UTC (permalink / raw)
To: ben; +Cc: p_gortmaker, netdev, 566522, sql7
In-Reply-To: <1270398809.8341.47.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Sun, 04 Apr 2010 17:33:29 +0100
> The driver attempts to select an IRQ for the NIC automatically by
> testing which of the supported IRQs are available and then probing
> each available IRQ with probe_irq_{on,off}(). There are obvious race
> conditions here, besides which:
> 1. The test for availability is done by passing a NULL handler, which
> now always returns -EINVAL, thus the device cannot be opened:
> <http://bugs.debian.org/566522>
> 2. probe_irq_off() will report only the first ISA IRQ handled,
> potentially leading to a false negative.
>
> There was another bug that meant it ignored all error codes from
> request_irq() except -EBUSY, so it would 'succeed' despite this
> (possibly causing conflicts with other ISA devices). This was fixed
> by ab08999d6029bb2c79c16be5405d63d2bedbdfea 'WARNING: some
> request_irq() failures ignored in el2_open()', which exposed bug 1.
>
> This patch:
> 1. Replaces the use of probe_irq_{on,off}() with a real interrupt handler
> 2. Adds a delay before checking the interrupt-seen flag
> 3. Disables interrupts on all failure paths
> 4. Distinguishes error codes from the second request_irq() call,
> consistently with the first
>
> Compile-tested only.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
This looks logically fine, but I'm tossing this into net-next-2.6
because of the limited tester space for this driver.
Thanks Ben.
^ permalink raw reply
* Re: [PATCH] cnic: Fix crash during bnx2x MTU change.
From: David Miller @ 2010-04-08 3:54 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1270518241-13750-1-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Mon, 5 Apr 2010 18:44:01 -0700
> cnic_service_bnx2x() irq handler can be called during chip reset from
> MTU change. Need to check that the cnic's device state is up before
> handling the irq.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied to net-2.6, thanks.
^ permalink raw reply
* Re: bridge: Fix IGMP3 report parsing
From: David Miller @ 2010-04-08 3:52 UTC (permalink / raw)
To: herbert; +Cc: netdev, banyeer
In-Reply-To: <20100408012634.GC18649@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 8 Apr 2010 09:26:34 +0800
> Hi:
>
> bridge: Fix IGMP3 report parsing
>
> The IGMP3 report parsing is looking at the wrong address for
> group records. This patch fixes it.
>
> Reported-by: Banyeer <banyeer@yahoo.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
I think you're adding as many bugs as you are fixing here :-)
> @@ -719,11 +719,11 @@ static int br_multicast_igmp3_report(struct net_bridge *br,
> len = sizeof(*ih);
>
> for (i = 0; i < num; i++) {
> + grec = (void *)(skb->data + len);
> len += sizeof(*grec);
> if (!pskb_may_pull(skb, len))
> return -EINVAL;
>
> - grec = (void *)(skb->data + len);
> group = grec->grec_mca;
> type = grec->grec_type;
>
If pskb_may_pull() actually does anything non-trivial,
skb->data will change and you'll be referring to freed
up memory.
That's probably why you had the grec assignment where
you originally had it in the first place :-)
^ permalink raw reply
* Re: [PATCH] rfs: Receive Flow Steering
From: Changli Gao @ 2010-04-08 1:37 UTC (permalink / raw)
To: Rick Jones; +Cc: Tom Herbert, Eric Dumazet, davem, netdev
In-Reply-To: <4BB6367D.9090600@hp.com>
On Sat, Apr 3, 2010 at 2:25 AM, Rick Jones <rick.jones2@hp.com> wrote:
> Tom Herbert wrote:
>> The progression in HP-UX was IPS (10.20) (aka RPS) then TOPS (11.0)
>> (aka RFS). We found that IPS was great for
>> single-flow-per-thread-of-execution stuff and that TOPS was better
>> for multiple-flow-per-thread-of-execution stuff. It was long enough
>> ago now that I can safely say for one system-level benchmark not
>> known to be a "networking" benchmark, and without a massive kernel
>> component, TOPS was a 10% win. Not too shabby.
>>
>> It wasn't that IPS wasn't good in its context - just that TOPS was
>> even better.
>>
>> I would assume that with IPS threads would migrate to where packets were
>> being delivered thus giving the same sort of locality TOPS was providing?
>> That would work great without any other constraints (multiple flows per
>> thread, thread CPU bindings, etc.).
>
> Well... that depended - at the time, and still, we were and are also
> encouraging users and app designers to make copious use of
> processor/locality affinity (SMP and NUMA going back far longer in the RISC
> et al space than the x86 space). So, it was and is entirely possible that
> the application thread of execution is hard-bound to a specific
> core/locality. Also, I do not recall if HP-UX was as aggressive about
> waking a process/thread on the processor from which the wake-up came vs on
> the processor on which it last ran.
>
Maybe RPS should be work against process not processor. For packets
forwarding, the process is net_rx softirq.
>> We also preferred the concept of the scheduler giving networking
>> clues as to where to process an application's packets rather than
>> networking trying to tell the scheduler. There was some discussion
>> of out of order worries, but we were willing to trust to the basic
>> soundness of the scheduler - if it was moving threads around willy
>> nilly at a rate able to cause big packet reordering it had
>> fundamental problems that would have to be addressed anyway.
>>
>>
>> I also think scheduler leading networking, like in RPS, is generally more
>> scalable. As for OOO packets, I've spent way to much time trying to
>> convince the bean-counters that a small number of them aren't problematic
>> :-), in the end it's just easier to not introduce new mechanisms that will
>> cause them!
>
> So long as it doesn't drive you to produce new mechanisms heavier than they
> would have otherwise been.
>
> The irony in the case of HP-UX IPS was that it was put in place in response
> to the severe out of order packet problems in HP-UX in 10.X before 10.20 -
> there were multiple netisr processes and only one netisr queue. The other
> little tweak that came along in 10.20 with IPS, was inaddition to having a
> per processor (well, per core in today's parlance) netisr queue, the netisr
> would grab the entire queue under the one spinlock and work off of that.
> That was nice because the code path became more efficient under load - more
> packets processed per spinlock/unlock pair.
>
RPS dispatches packets among all the CPUs permitted fairly, in order
to take full advantage of all the CPU power. The assumption is the cpu
cycles each CPU gives to packet processing are the same. But it isn't
always true as scheduler is mixed in. In this case, scheduler leading
network is a good choice. Maybe we should make softirq threaded under
the control of scheduler. And the number of softirq threads can be
specified by users. By default, the number of the softirq threads are
the same as the number of CPUs, and each thread binds to a special
CPU, to keep the current behavior. If the other tasks aren't
dispatched among the CPUs even, system administrator may increase the
number of softirq thread, and dissolve the thread binding, then there
will be enough schedulable softirq threads for scheduler scheduling.
Oh, maybe there is no need of weighted packets dispatching RPS.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ 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