* Re: [PATCH] Speed-up pfifo_fast lookup using a bitmap
From: Krishna Kumar @ 2009-08-14 8:19 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: kaber, netdev, davem, Krishna Kumar, herbert
Jarek Poplawski <jarkao2@gmail.com> wrote on 08/13/2009 04:57:16 PM:
> > Sounds reasonable. To quantify that, I will test again for a longer
> > run and report the difference.
>
> Yes, more numbers would be appreciated.
I did a longer 7-hour testing of original code, public bitmap (the
code submitted earlier) and a private bitmap (patch below). Each
result line is aggregate of 5 iterations of individual 1, 2, 4, 8,
32 netperf sessions, each running for 55 seconds:
-------------------------------------------------------
IO Size Org Public Private
-------------------------------------------------------
4K 122571 126821 125913
16K 135715 135642 135530
128K 131324 131862 131668
256K 130060 130107 130378
-------------------------------------------------------
Total: 519670 524433 (0.92%) 523491 (0.74%)
-------------------------------------------------------
The difference between keeping the bitmap private and public is
not much.
> > The tests are on the latest tree which contains CAN_BYPASS. So a
> > single netperf process running this change will get no advantage
> > since this enqueue/dequeue never happens unless the NIC is slow.
> > But for multiple processes, it should help.
>
> I mean: since the previous patch saved ~2% on omitting enqueue/dequeue,
> and now enqueue/dequeue is ~2% faster, is it still worth to omit this?
I haven't tested the bitmap patch without the bypass code.
Theoretically I assume that patch should help as we still save
an enqueue/dequeue.
Thanks,
- KK
Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
---
net/sched/sch_generic.c | 70 ++++++++++++++++++++++++++------------
1 file changed, 48 insertions(+), 22 deletions(-)
diff -ruNp org/net/sched/sch_generic.c new2/net/sched/sch_generic.c
--- org/net/sched/sch_generic.c 2009-08-07 12:05:43.000000000 +0530
+++ new2/net/sched/sch_generic.c 2009-08-14 12:48:37.000000000 +0530
@@ -406,18 +406,38 @@ static const u8 prio2band[TC_PRIO_MAX+1]
#define PFIFO_FAST_BANDS 3
-static inline struct sk_buff_head *prio2list(struct sk_buff *skb,
- struct Qdisc *qdisc)
+/*
+ * Private data for a pfifo_fast scheduler containing:
+ * - the three band queues
+ * - bitmap indicating which of the bands contain skbs.
+ */
+struct pfifo_fast_priv {
+ u32 bitmap;
+ struct sk_buff_head q[PFIFO_FAST_BANDS];
+};
+
+/*
+ * Convert a bitmap to the first band number where an skb is queued, where:
+ * bitmap=0 means there are no skbs on any bands.
+ * bitmap=1 means there is an skb on band 0.
+ * bitmap=7 means there are skbs on all 3 bands, etc.
+ */
+static const int bitmap2band[] = {-1, 0, 1, 0, 2, 0, 1, 0};
+
+static inline struct sk_buff_head *band2list(struct pfifo_fast_priv *priv,
+ int band)
{
- struct sk_buff_head *list = qdisc_priv(qdisc);
- return list + prio2band[skb->priority & TC_PRIO_MAX];
+ return &priv->q[0] + band;
}
static int pfifo_fast_enqueue(struct sk_buff *skb, struct Qdisc* qdisc)
{
- struct sk_buff_head *list = prio2list(skb, qdisc);
+ int band = prio2band[skb->priority & TC_PRIO_MAX];
+ struct pfifo_fast_priv *priv = qdisc_priv(qdisc);
+ struct sk_buff_head *list = band2list(priv, band);
if (skb_queue_len(list) < qdisc_dev(qdisc)->tx_queue_len) {
+ priv->bitmap |= (1 << band);
qdisc->q.qlen++;
return __qdisc_enqueue_tail(skb, qdisc, list);
}
@@ -427,14 +447,18 @@ static int pfifo_fast_enqueue(struct sk_
static struct sk_buff *pfifo_fast_dequeue(struct Qdisc* qdisc)
{
- int prio;
- struct sk_buff_head *list = qdisc_priv(qdisc);
+ struct pfifo_fast_priv *priv = qdisc_priv(qdisc);
+ int band = bitmap2band[priv->bitmap];
- for (prio = 0; prio < PFIFO_FAST_BANDS; prio++) {
- if (!skb_queue_empty(list + prio)) {
- qdisc->q.qlen--;
- return __qdisc_dequeue_head(qdisc, list + prio);
- }
+ if (likely(band >= 0)) {
+ struct sk_buff_head *list = band2list(priv, band);
+ struct sk_buff *skb = __qdisc_dequeue_head(qdisc, list);
+
+ qdisc->q.qlen--;
+ if (skb_queue_empty(list))
+ priv->bitmap &= ~(1 << band);
+
+ return skb;
}
return NULL;
@@ -442,12 +466,13 @@ static struct sk_buff *pfifo_fast_dequeu
static struct sk_buff *pfifo_fast_peek(struct Qdisc* qdisc)
{
- int prio;
- struct sk_buff_head *list = qdisc_priv(qdisc);
+ struct pfifo_fast_priv *priv = qdisc_priv(qdisc);
+ int band = bitmap2band[priv->bitmap];
+
+ if (band >= 0) {
+ struct sk_buff_head *list = band2list(priv, band);
- for (prio = 0; prio < PFIFO_FAST_BANDS; prio++) {
- if (!skb_queue_empty(list + prio))
- return skb_peek(list + prio);
+ return skb_peek(list);
}
return NULL;
@@ -456,11 +481,12 @@ static struct sk_buff *pfifo_fast_peek(s
static void pfifo_fast_reset(struct Qdisc* qdisc)
{
int prio;
- struct sk_buff_head *list = qdisc_priv(qdisc);
+ struct pfifo_fast_priv *priv = qdisc_priv(qdisc);
for (prio = 0; prio < PFIFO_FAST_BANDS; prio++)
- __qdisc_reset_queue(qdisc, list + prio);
+ __qdisc_reset_queue(qdisc, band2list(priv, prio));
+ priv->bitmap = 0;
qdisc->qstats.backlog = 0;
qdisc->q.qlen = 0;
}
@@ -480,17 +506,17 @@ nla_put_failure:
static int pfifo_fast_init(struct Qdisc *qdisc, struct nlattr *opt)
{
int prio;
- struct sk_buff_head *list = qdisc_priv(qdisc);
+ struct pfifo_fast_priv *priv = qdisc_priv(qdisc);
for (prio = 0; prio < PFIFO_FAST_BANDS; prio++)
- skb_queue_head_init(list + prio);
+ skb_queue_head_init(band2list(priv, prio));
return 0;
}
static struct Qdisc_ops pfifo_fast_ops __read_mostly = {
.id = "pfifo_fast",
- .priv_size = PFIFO_FAST_BANDS * sizeof(struct sk_buff_head),
+ .priv_size = sizeof (struct pfifo_fast_priv),
.enqueue = pfifo_fast_enqueue,
.dequeue = pfifo_fast_dequeue,
.peek = pfifo_fast_peek,
^ permalink raw reply
* Re: [RFC] ipv6: Change %pI6 format to output compacted addresses?
From: Jens Rosenboom @ 2009-08-14 8:15 UTC (permalink / raw)
To: David Miller; +Cc: joe, chuck.lever, brian.haley, netdev
In-Reply-To: <20090814.001519.40499255.davem@davemloft.net>
On Fri, 2009-08-14 at 00:15 -0700, David Miller wrote:
> From: Jens Rosenboom <jens@mcbone.net>
> Date: Fri, 14 Aug 2009 08:22:05 +0200
>
> > On Thu, 2009-08-13 at 16:31 -0700, David Miller wrote:
> >> From: Joe Perches <joe@perches.com>
> >> Date: Thu, 13 Aug 2009 14:13:42 -0700
> >>
> >> > On Thu, 2009-08-13 at 17:02 -0400, Chuck Lever wrote:
> >> >> [ I would think user space in general should be using inet_pton(3)
> >> >> everywhere for such interfaces, so the format of these addresses
> >> >> wouldn't matter so much. Probably impossible at this point. ]
> >> >
> >> > David Miller is authoritative here.
> >>
> >> In the final analysis, the risk is just too high to break
> >> userspace. So let's play conservative here and not change
> >> the output for currently user visible stuff.
> >
> > So just to clarify, do you want us to drop the whole thread and stay
> > with the clumsy output, or would you be o.k. with adding a new
> > %p{something} and use that for kernel messages and maybe do some slow
> > migration of other stuff where possible?
>
> You tell me what part of this you don't understand:
>
> So let's play conservative here and not change
> the output for currently user visible stuff.
>
> I can't figure out a way to express that more clearly than I did.
I wasn't sure whether "currently user visible stuff" would mean "user
space interfaces" like sys/proc-fs, which the first quoted post asked
about, or also kernel messages.
^ permalink raw reply
* Re: [PATCH net-2.6] can: Use WARN_ONCE() instead of BUG_ON() for sanity check in receive path
From: Oliver Hartkopp @ 2009-08-14 8:11 UTC (permalink / raw)
To: David Miller; +Cc: urs, l.fu, m.olbrich, netdev
In-Reply-To: <20090814.001322.146991956.davem@davemloft.net>
David Miller wrote:
> From: Oliver Hartkopp <oliver@hartkopp.net>
> Date: Fri, 14 Aug 2009 07:57:02 +0200
>
>> David Miller wrote:
>>> From: Oliver Hartkopp <oliver@hartkopp.net>
>>> Date: Mon, 10 Aug 2009 13:27:09 +0200
>>>
>>>> Additionally it changes the return values to the common NET_RX_xxx constants.
>>> Don't munge unrelated changes together like this, split it up.
>>>
>>> Also, this is not net-2.6 material, I will only apply these changes
>>> to net-next-2.6 at this point.
>> No problem.
>>
>> Btw. this patch was removed from patchwork and i was not able to find it in
>> your latest net-next-2.6 push this morning.
>
> It's not in net-next-2.6 because I didn't apply it, which is pretty
> clealy implied when I'm asking you to split the change up into
> multiple patches.
Sorry - i assumed this to be a hint for the next time. My fault.
>
> When I ask for changes, I mark the patch in patchwork with the
> "changes requested" state and expect you to send me new updated stuff.
>
> You can look for patches in various "done" states by simply modifying
> the "Filters" setting in the patch list.
Ah! I only had the filters on 'action required' and therefore is was not able
to see what happened after the patches were removed from the 'action required'
view ...
I'll re-send two separate patches for net-next-2.6 .
Thanks,
Oliver
^ permalink raw reply
* Re: [RFC] ipv6: Change %pI6 format to output compacted addresses?
From: David Miller @ 2009-08-14 7:15 UTC (permalink / raw)
To: jens; +Cc: joe, chuck.lever, brian.haley, netdev
In-Reply-To: <1250230925.6641.92.camel@fnki-nb00130>
From: Jens Rosenboom <jens@mcbone.net>
Date: Fri, 14 Aug 2009 08:22:05 +0200
> On Thu, 2009-08-13 at 16:31 -0700, David Miller wrote:
>> From: Joe Perches <joe@perches.com>
>> Date: Thu, 13 Aug 2009 14:13:42 -0700
>>
>> > On Thu, 2009-08-13 at 17:02 -0400, Chuck Lever wrote:
>> >> [ I would think user space in general should be using inet_pton(3)
>> >> everywhere for such interfaces, so the format of these addresses
>> >> wouldn't matter so much. Probably impossible at this point. ]
>> >
>> > David Miller is authoritative here.
>>
>> In the final analysis, the risk is just too high to break
>> userspace. So let's play conservative here and not change
>> the output for currently user visible stuff.
>
> So just to clarify, do you want us to drop the whole thread and stay
> with the clumsy output, or would you be o.k. with adding a new
> %p{something} and use that for kernel messages and maybe do some slow
> migration of other stuff where possible?
You tell me what part of this you don't understand:
So let's play conservative here and not change
the output for currently user visible stuff.
I can't figure out a way to express that more clearly than I did.
^ permalink raw reply
* Re: [PATCH net-2.6] can: Use WARN_ONCE() instead of BUG_ON() for sanity check in receive path
From: David Miller @ 2009-08-14 7:13 UTC (permalink / raw)
To: oliver; +Cc: urs, l.fu, m.olbrich, netdev
In-Reply-To: <4A84FCAE.10309@hartkopp.net>
From: Oliver Hartkopp <oliver@hartkopp.net>
Date: Fri, 14 Aug 2009 07:57:02 +0200
> David Miller wrote:
>> From: Oliver Hartkopp <oliver@hartkopp.net>
>> Date: Mon, 10 Aug 2009 13:27:09 +0200
>>
>>> Additionally it changes the return values to the common NET_RX_xxx constants.
>>
>> Don't munge unrelated changes together like this, split it up.
>>
>> Also, this is not net-2.6 material, I will only apply these changes
>> to net-next-2.6 at this point.
>
> No problem.
>
> Btw. this patch was removed from patchwork and i was not able to find it in
> your latest net-next-2.6 push this morning.
It's not in net-next-2.6 because I didn't apply it, which is pretty
clealy implied when I'm asking you to split the change up into
multiple patches.
When I ask for changes, I mark the patch in patchwork with the
"changes requested" state and expect you to send me new updated stuff.
You can look for patches in various "done" states by simply modifying
the "Filters" setting in the patch list.
^ permalink raw reply
* Re: [Bugme-new] [Bug 13954] New: Oops in rtnetlink code when creating can device
From: Oliver Hartkopp @ 2009-08-14 6:23 UTC (permalink / raw)
Cc: Andrew Morton, kaber, Wolfgang Grandegger, dbaryshkov,
bugzilla-daemon, bugme-daemon, Thuermann, Urs, Dr. (K-EFFI/I),
Lothar Wassmann, netdev
In-Reply-To: <4A812354.8090704@volkswagen.de>
Oliver Hartkopp wrote:
> Andrew Morton wrote:
>> (switched to email. Please respond via emailed reply-to-all, not via the
>> bugzilla web interface).
>>
>> On Mon, 10 Aug 2009 11:34:28 GMT bugzilla-daemon@bugzilla.kernel.org
>> wrote:
>>
>>
>>> http://bugzilla.kernel.org/show_bug.cgi?id=13954
>>>
>>
>> Thanks.
>>
>>
>>> Summary: Oops in rtnetlink code when creating can device
>>> Product: Networking
>>> Version: 2.5
>>> Kernel Version: 2.6.30-rc5
>>> Platform: All
>>> OS/Version: Linux
>>> Tree: Mainline
>>> Status: NEW
>>> Severity: normal
>>> Priority: P1
>>> Component: Other
>>> AssignedTo: acme@ghostprotocols.net
>>> ReportedBy: dbaryshkov@gmail.com
>>> Regression: No
>>>
>>>
>>> I've got a nice oops when looking around new CAN code in kernel.
>>>
>>> root@qemux86:~# ip link add type can
>>> [ 713.113325] BUG: unable to handle kernel NULL pointer dereference
>>> at (null)
>>> [ 713.114216] IP: [<c13eecab>] register_netdevice+0xab/0x420
>>> [ 713.114920] *pdpt = 00000000061bd001 *pde = 0000000000000000 [
>>> 713.115627] Oops: 0000 [#1] SMP [ 713.115972] last sysfs file:
>>> /sys/devices/virtual/backlight/fujitsu-laptop/brightness
>>> [ 713.116137] Modules linked in:
>>> [ 713.116137] [ 713.116137] Pid: 1803, comm: ip Not tainted
>>> (2.6.31-rc5 #68) [ 713.116137] EIP: 0060:[<c13eecab>] EFLAGS:
>>> 00000246 CPU: 0
>>> [ 713.116137] EIP is at register_netdevice+0xab/0x420
>>> [ 713.116137] EAX: 00000000 EBX: 00000000 ECX: 00000001 EDX: 00000001
>>> [ 713.116137] ESI: c72c6000 EDI: 00000000 EBP: c61abb54 ESP: c61abb34
>>> [ 713.116137] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
>>> [ 713.116137] Process ip (pid: 1803, ti=c61aa000 task=c6f395e0
>>> task.ti=c61aa000)
>>> [ 713.116137] Stack:
>>> [ 713.116137] c61abb54 c13f732f 00000001 c61abbb4 894f908a 00000000
>>> c72c6000
>>> 00000000
>>> [ 713.116137] <0> c61abc74 c13f8278 c61abbb4 00000010 c165d494 c1652090
>>> c61abc18 c6f3d028
>>> [ 713.116137] <0> 894f908a 894f908a c61abc18 c13f7da0 c61abc74 c13f7f46
>>> 00000008 c1546f80
>>> [ 713.116137] Call Trace:
>>> [ 713.116137] [<c13f732f>] ? rtnl_create_link+0x4f/0x130
>>> [ 713.116137] [<c13f8278>] ? rtnl_newlink+0x4d8/0x4e0
>>> [ 713.116137] [<c13f7da0>] ? rtnl_newlink+0x0/0x4e0
>>> [ 713.116137] [<c13f7f46>] ? rtnl_newlink+0x1a6/0x4e0
>>> [ 713.116137] [<c13f7da0>] ? rtnl_newlink+0x0/0x4e0
>>> [ 713.116137] [<c13f7d00>] ? rtnetlink_rcv_msg+0x180/0x220
>>> [ 713.116137] [<c13f7b80>] ? rtnetlink_rcv_msg+0x0/0x220
>>> [ 713.116137] [<c1400e56>] ? netlink_rcv_skb+0x86/0xb0
>>> [ 713.116137] [<c13f7b5a>] ? rtnetlink_rcv+0x2a/0x50
>>>
>
Just to close this issue:
The patch has just been committed by Dave to net-2.6 for 2.6.31 upstream ...
http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commitdiff;h=993e6f2fd487e2acddd711f79cf48f3420731382
Thanks to all of you.
Oliver
^ permalink raw reply
* Re: [RFC] ipv6: Change %pI6 format to output compacted addresses?
From: Jens Rosenboom @ 2009-08-14 6:22 UTC (permalink / raw)
To: David Miller; +Cc: joe, chuck.lever, brian.haley, netdev
In-Reply-To: <20090813.163133.199571497.davem@davemloft.net>
On Thu, 2009-08-13 at 16:31 -0700, David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Thu, 13 Aug 2009 14:13:42 -0700
>
> > On Thu, 2009-08-13 at 17:02 -0400, Chuck Lever wrote:
> >> [ I would think user space in general should be using inet_pton(3)
> >> everywhere for such interfaces, so the format of these addresses
> >> wouldn't matter so much. Probably impossible at this point. ]
> >
> > David Miller is authoritative here.
>
> In the final analysis, the risk is just too high to break
> userspace. So let's play conservative here and not change
> the output for currently user visible stuff.
So just to clarify, do you want us to drop the whole thread and stay
with the clumsy output, or would you be o.k. with adding a new
%p{something} and use that for kernel messages and maybe do some slow
migration of other stuff where possible?
^ permalink raw reply
* Re: [PATCH net-2.6] can: Use WARN_ONCE() instead of BUG_ON() for sanity check in receive path
From: Oliver Hartkopp @ 2009-08-14 5:57 UTC (permalink / raw)
To: David Miller; +Cc: urs, l.fu, m.olbrich, netdev
In-Reply-To: <20090812.220123.234730484.davem@davemloft.net>
David Miller wrote:
> From: Oliver Hartkopp <oliver@hartkopp.net>
> Date: Mon, 10 Aug 2009 13:27:09 +0200
>
>> Additionally it changes the return values to the common NET_RX_xxx constants.
>
> Don't munge unrelated changes together like this, split it up.
>
> Also, this is not net-2.6 material, I will only apply these changes
> to net-next-2.6 at this point.
No problem.
Btw. this patch was removed from patchwork and i was not able to find it in
your latest net-next-2.6 push this morning.
Best regards,
Oliver
^ permalink raw reply
* [PATCH] drivers/net: fixed drivers that support netpoll use ndo_start_xmit()
From: DDD @ 2009-08-14 5:12 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, Ashfield, Bruce, jason.wessel
The NETPOLL API requires that interrupts remain disabled in
netpoll_send_skb(). The use of spin_lock_irq() and spin_unlock_irq()
in the NETPOLL API callbacks causes the interrupts to get enabled and
can lead to kernel instability.
The solution is to use spin_lock_irqsave() and spin_unlock_restore()
to prevent the irqs from getting enabled while in netpoll_send_skb().
Call trace:
netpoll_send_skb()
{
-> local_irq_save(flags)
---> dev->ndo_start_xmit(skb, dev)
---> spin_lock_irq()
---> spin_unlock_irq() *******here would enable the interrupt.
...
-> local_irq_restore(flags)
}
Signed-off-by: Dongdong Deng <dongdong.deng@windriver.com>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Acked-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
drivers/net/b44.c | 5 +++--
drivers/net/tulip/tulip_core.c | 5 +++--
drivers/net/ucc_geth.c | 5 +++--
drivers/net/via-rhine.c | 5 +++--
4 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/net/b44.c b/drivers/net/b44.c
index 36d4d37..bafca67 100644
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -952,9 +952,10 @@ static int b44_start_xmit(struct sk_buff *skb, struct net_device *dev)
int rc = NETDEV_TX_OK;
dma_addr_t mapping;
u32 len, entry, ctrl;
+ unsigned long flags;
len = skb->len;
- spin_lock_irq(&bp->lock);
+ spin_lock_irqsave(&bp->lock, flags);
/* This is a hard error, log it. */
if (unlikely(TX_BUFFS_AVAIL(bp) < 1)) {
@@ -1027,7 +1028,7 @@ static int b44_start_xmit(struct sk_buff *skb, struct net_device *dev)
dev->trans_start = jiffies;
out_unlock:
- spin_unlock_irq(&bp->lock);
+ spin_unlock_irqrestore(&bp->lock, flags);
return rc;
diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
index 99a6364..4cf9a65 100644
--- a/drivers/net/tulip/tulip_core.c
+++ b/drivers/net/tulip/tulip_core.c
@@ -652,8 +652,9 @@ tulip_start_xmit(struct sk_buff *skb, struct net_device *dev)
int entry;
u32 flag;
dma_addr_t mapping;
+ unsigned long flags;
- spin_lock_irq(&tp->lock);
+ spin_lock_irqsave(&tp->lock, flags);
/* Calculate the next Tx descriptor entry. */
entry = tp->cur_tx % TX_RING_SIZE;
@@ -688,7 +689,7 @@ tulip_start_xmit(struct sk_buff *skb, struct net_device *dev)
/* Trigger an immediate transmit demand. */
iowrite32(0, tp->base_addr + CSR1);
- spin_unlock_irq(&tp->lock);
+ spin_unlock_irqrestore(&tp->lock, flags);
dev->trans_start = jiffies;
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 3b957e6..8a7b8c7 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3111,10 +3111,11 @@ static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
u8 __iomem *bd; /* BD pointer */
u32 bd_status;
u8 txQ = 0;
+ unsigned long flags;
ugeth_vdbg("%s: IN", __func__);
- spin_lock_irq(&ugeth->lock);
+ spin_lock_irqsave(&ugeth->lock, flags);
dev->stats.tx_bytes += skb->len;
@@ -3171,7 +3172,7 @@ static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
uccf = ugeth->uccf;
out_be16(uccf->p_utodr, UCC_FAST_TOD);
#endif
- spin_unlock_irq(&ugeth->lock);
+ spin_unlock_irqrestore(&ugeth->lock, flags);
return 0;
}
diff --git a/drivers/net/via-rhine.c b/drivers/net/via-rhine.c
index 88c30a5..934f767 100644
--- a/drivers/net/via-rhine.c
+++ b/drivers/net/via-rhine.c
@@ -1218,6 +1218,7 @@ static int rhine_start_tx(struct sk_buff *skb, struct net_device *dev)
struct rhine_private *rp = netdev_priv(dev);
void __iomem *ioaddr = rp->base;
unsigned entry;
+ unsigned long flags;
/* Caution: the write order is important here, set the field
with the "ownership" bits last. */
@@ -1261,7 +1262,7 @@ static int rhine_start_tx(struct sk_buff *skb, struct net_device *dev)
cpu_to_le32(TXDESC | (skb->len >= ETH_ZLEN ? skb->len : ETH_ZLEN));
/* lock eth irq */
- spin_lock_irq(&rp->lock);
+ spin_lock_irqsave(&rp->lock, flags);
wmb();
rp->tx_ring[entry].tx_status = cpu_to_le32(DescOwn);
wmb();
@@ -1280,7 +1281,7 @@ static int rhine_start_tx(struct sk_buff *skb, struct net_device *dev)
dev->trans_start = jiffies;
- spin_unlock_irq(&rp->lock);
+ spin_unlock_irqrestore(&rp->lock, flags);
if (debug > 4) {
printk(KERN_DEBUG "%s: Transmit frame #%d queued in slot %d.\n",
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] s2io: Remove unnecessary casts
From: Davidlohr Bueso @ 2009-08-14 3:57 UTC (permalink / raw)
To: David Miller
Cc: ram.vepa, santosh.rastapur, sivakumar.subramani,
sreenivasa.honnur, anil.murthy, netdev, kernel-janitors
In-Reply-To: <20090813.201452.21119996.davem@davemloft.net>
On Thu, Aug 13, 2009 at 08:14:52PM -0700, David Miller wrote:
> From: Davidlohr Bueso <dave@gnu.org>
> Date: Thu, 13 Aug 2009 22:03:28 -0400
>
> >
> > No need to cast kmalloc.
> >
> > Signed-off-by: Davidlohr Bueso <dave@gnu.org>
>
> Yeah but:
>
> >
> > - ba->ba_0_org = (void *) kmalloc
> > - (BUF0_LEN + ALIGN_SIZE, GFP_KERNEL);
> > + ba->ba_0_org = kmalloc(BUF0_LEN + ALIGN_SIZE, GFP_KERNEL);
>
> Now the code line extends way over 80 columns.
Ok, resubmitting and verified by checkpatch.pl
Thanks.
Signed-off-by: Davidlohr Bueso <dave@gnu.org>
---
drivers/net/s2io.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
index 458daa0..2bc62d3 100644
--- a/drivers/net/s2io.c
+++ b/drivers/net/s2io.c
@@ -870,8 +870,10 @@ static int init_shared_mem(struct s2io_nic *nic)
while (k != rxd_count[nic->rxd_mode]) {
ba = &mac_control->rings[i].ba[j][k];
- ba->ba_0_org = (void *) kmalloc
- (BUF0_LEN + ALIGN_SIZE, GFP_KERNEL);
+ ba->ba_0_org = kmalloc
+ (BUF0_LEN + ALIGN_SIZE,
+ GFP_KERNEL);
+
if (!ba->ba_0_org)
return -ENOMEM;
mem_allocated +=
@@ -881,8 +883,10 @@ static int init_shared_mem(struct s2io_nic *nic)
tmp &= ~((unsigned long) ALIGN_SIZE);
ba->ba_0 = (void *) tmp;
- ba->ba_1_org = (void *) kmalloc
- (BUF1_LEN + ALIGN_SIZE, GFP_KERNEL);
+ ba->ba_1_org = kmalloc
+ (BUF1_LEN + ALIGN_SIZE,
+ GFP_KERNEL);
+
if (!ba->ba_1_org)
return -ENOMEM;
mem_allocated
^ permalink raw reply related
* Re: [PATCH] s2io: Remove unnecessary casts
From: David Miller @ 2009-08-14 3:14 UTC (permalink / raw)
To: dave
Cc: ram.vepa, santosh.rastapur, sivakumar.subramani,
sreenivasa.honnur, anil.murthy, netdev, kernel-janitors
In-Reply-To: <20090814020328.GA21588@fencepost.gnu.org>
From: Davidlohr Bueso <dave@gnu.org>
Date: Thu, 13 Aug 2009 22:03:28 -0400
>
> No need to cast kmalloc.
>
> Signed-off-by: Davidlohr Bueso <dave@gnu.org>
Yeah but:
>
> - ba->ba_0_org = (void *) kmalloc
> - (BUF0_LEN + ALIGN_SIZE, GFP_KERNEL);
> + ba->ba_0_org = kmalloc(BUF0_LEN + ALIGN_SIZE, GFP_KERNEL);
Now the code line extends way over 80 columns.
Please fix this up and resubmit.
^ permalink raw reply
* Re: [net-2.6 PATCH 2/2] ixgbe: Do not return 0 in ixgbe_fcoe_ddp() upon FCP_RSP in DDP completion
From: David Miller @ 2009-08-14 3:14 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, yi.zou, peter.p.waskiewicz.jr
In-Reply-To: <20090814000958.20911.72817.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 13 Aug 2009 17:09:58 -0700
> From: Yi Zou <yi.zou@intel.com>
>
> We return the ddp->len in ixgbe_fcoe_ddp() to indicate the length of data that
> have been DDPed. However, it is possible that the length is 0, e.g., for SCSI
> READ, the FCP_RSP may come back w/ SCSI status 0x28 as Task Set Full with no FCP
> data for DDP. In ixgbe_fcoe_ddp(), we return 0 to indicate not passing DDPed
> packets to upper layer. Therefore in the case of ddp->len being 0 upon FCP_RSP,
> we do not want to return the 0 ddp->len as we want FCP_RSP to be always
> delivered to the upper layer. This patch fixes this bug by setting rc only if
> ddp->len is non-zero.
>
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 1/2] ixgbe: Fix receive on real device when VLANs are configured
From: David Miller @ 2009-08-14 3:14 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, lucy.liu, peter.p.waskiewicz.jr
In-Reply-To: <20090814000929.20911.77027.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 13 Aug 2009 17:09:38 -0700
> From: Lucy Liu <lucy.liu@intel.com>
>
> Traffic received with a priority tag (VID = 0) and non-zero priority value was
> incorrectly handled by the VLAN packet code path due to a check on zero for
> the whole VLAN tag instead of just the VID.
>
> This patch masked out the priority field when checking the vlan tag for
> received VLAN packets.
>
> Signed-off-by: Lucy Liu <lucy.liu@intel.com>
> Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* [PATCH] s2io: Remove unnecessary casts
From: Davidlohr Bueso @ 2009-08-14 2:03 UTC (permalink / raw)
To: ram.vepa, santosh.rastapur, sivakumar.subramani,
sreenivasa.honnur, anil.murthy
Cc: netdev, kernel-janitors
No need to cast kmalloc.
Signed-off-by: Davidlohr Bueso <dave@gnu.org>
---
drivers/net/s2io.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
index 458daa0..43a5abf 100644
--- a/drivers/net/s2io.c
+++ b/drivers/net/s2io.c
@@ -870,8 +870,7 @@ static int init_shared_mem(struct s2io_nic *nic)
while (k != rxd_count[nic->rxd_mode]) {
ba = &mac_control->rings[i].ba[j][k];
- ba->ba_0_org = (void *) kmalloc
- (BUF0_LEN + ALIGN_SIZE, GFP_KERNEL);
+ ba->ba_0_org = kmalloc(BUF0_LEN + ALIGN_SIZE, GFP_KERNEL);
if (!ba->ba_0_org)
return -ENOMEM;
mem_allocated +=
@@ -881,8 +880,7 @@ static int init_shared_mem(struct s2io_nic *nic)
tmp &= ~((unsigned long) ALIGN_SIZE);
ba->ba_0 = (void *) tmp;
- ba->ba_1_org = (void *) kmalloc
- (BUF1_LEN + ALIGN_SIZE, GFP_KERNEL);
+ ba->ba_1_org = kmalloc(BUF1_LEN + ALIGN_SIZE, GFP_KERNEL);
if (!ba->ba_1_org)
return -ENOMEM;
mem_allocated
^ permalink raw reply related
* Re: [PATCH 1/3] Networking: use CAP_NET_ADMIN when deciding to call request_module
From: James Morris @ 2009-08-14 1:56 UTC (permalink / raw)
To: Eric Paris
Cc: linux-kernel, selinux, netdev, linux-security-module, sds, davem,
shemminger, kees, morgan, casey, dwalsh
In-Reply-To: <20090813134451.29186.41664.stgit@paris.rdu.redhat.com>
On Thu, 13 Aug 2009, Eric Paris wrote:
> The networking code checks CAP_SYS_MODULE before using request_module() to
I applied all three patches to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next
and fixed up the documentation per Serge's suggestion.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Reminder Notification!!
From: KGSBV.NL @ 2009-08-13 23:21 UTC (permalink / raw)
To: frk0061
2009 Prize Award!!
Winning/Confirm!!
This email is to notify you that you have won an Award Sum of ?500,000.00 (Five Hundred Thousand Euros)in an E-mail program held in Den Haag, The Netherlands.
Please contact the claim officer with your winning info. REF NUM.(NL80246) BATCH NUM.(EU-0375908NL) TICKET NUM.(460205)Name;Mr.Paul Hanson,TEL.+31-643608961,E-mail:spbg09@aol.nl.
Yours Sincerely,
Mr. Robert Tibert,
Public Relation Officer.
^ permalink raw reply
* Reminder Notification!!
From: KGSBV.NL @ 2009-08-14 0:40 UTC (permalink / raw)
To: frk0061
2009 Prize Award!!
Winning/Confirm!!
This email is to notify you that you have won an Award Sum of ?500,000.00 (Five Hundred Thousand Euros)in an E-mail program held in Den Haag, The Netherlands.
Please contact the claim officer with your winning info. REF NUM.(NL80246) BATCH NUM.(EU-0375908NL) TICKET NUM.(460205)Name;Mr.Paul Hanson,TEL.+31-643608961,E-mail:spbg09@aol.nl.
Yours Sincerely,
Mr. Robert Tibert,
Public Relation Officer.
^ permalink raw reply
* [net-2.6 PATCH 2/2] ixgbe: Do not return 0 in ixgbe_fcoe_ddp() upon FCP_RSP in DDP completion
From: Jeff Kirsher @ 2009-08-14 0:09 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Yi Zou, Peter P Waskiewicz Jr, Jeff Kirsher
In-Reply-To: <20090814000929.20911.77027.stgit@localhost.localdomain>
From: Yi Zou <yi.zou@intel.com>
We return the ddp->len in ixgbe_fcoe_ddp() to indicate the length of data that
have been DDPed. However, it is possible that the length is 0, e.g., for SCSI
READ, the FCP_RSP may come back w/ SCSI status 0x28 as Task Set Full with no FCP
data for DDP. In ixgbe_fcoe_ddp(), we return 0 to indicate not passing DDPed
packets to upper layer. Therefore in the case of ddp->len being 0 upon FCP_RSP,
we do not want to return the 0 ddp->len as we want FCP_RSP to be always
delivered to the upper layer. This patch fixes this bug by setting rc only if
ddp->len is non-zero.
Signed-off-by: Yi Zou <yi.zou@intel.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_fcoe.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_fcoe.c b/drivers/net/ixgbe/ixgbe_fcoe.c
index fa9f24e..28cf104 100644
--- a/drivers/net/ixgbe/ixgbe_fcoe.c
+++ b/drivers/net/ixgbe/ixgbe_fcoe.c
@@ -336,7 +336,7 @@ int ixgbe_fcoe_ddp(struct ixgbe_adapter *adapter,
/* return 0 to bypass going to ULD for DDPed data */
if (fcstat == IXGBE_RXDADV_STAT_FCSTAT_DDP)
rc = 0;
- else
+ else if (ddp->len)
rc = ddp->len;
}
^ permalink raw reply related
* [net-2.6 PATCH 1/2] ixgbe: Fix receive on real device when VLANs are configured
From: Jeff Kirsher @ 2009-08-14 0:09 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Lucy Liu, Peter P Waskiewicz Jr, Jeff Kirsher
From: Lucy Liu <lucy.liu@intel.com>
Traffic received with a priority tag (VID = 0) and non-zero priority value was
incorrectly handled by the VLAN packet code path due to a check on zero for
the whole VLAN tag instead of just the VID.
This patch masked out the priority field when checking the vlan tag for
received VLAN packets.
Signed-off-by: Lucy Liu <lucy.liu@intel.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index e3cb949..77b0381 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -492,12 +492,12 @@ static void ixgbe_receive_skb(struct ixgbe_q_vector *q_vector,
skb_record_rx_queue(skb, ring->queue_index);
if (!(adapter->flags & IXGBE_FLAG_IN_NETPOLL)) {
- if (adapter->vlgrp && is_vlan && (tag != 0))
+ if (adapter->vlgrp && is_vlan && (tag & VLAN_VID_MASK))
vlan_gro_receive(napi, adapter->vlgrp, tag, skb);
else
napi_gro_receive(napi, skb);
} else {
- if (adapter->vlgrp && is_vlan && (tag != 0))
+ if (adapter->vlgrp && is_vlan && (tag & VLAN_VID_MASK))
vlan_hwaccel_rx(skb, adapter->vlgrp, tag);
else
netif_rx(skb);
^ permalink raw reply related
* [linux-next PATCH] pci: add update 82576 device ids to SR-IOV quirks list
From: Jeff Kirsher @ 2009-08-13 23:57 UTC (permalink / raw)
To: jbarnes; +Cc: linux-pci, netdev, davem, gospo, Alexander Duyck, Jeff Kirsher
From: Alexander Duyck <alexander.h.duyck@intel.com>
This patch adds the most recent additions to the list of 82576 device IDs
to the list of devices needing the SR-IOV quirk.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/pci/quirks.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 06b9656..8d25670 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -2492,6 +2492,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x10e6, quirk_i82576_sriov);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x10e7, quirk_i82576_sriov);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x10e8, quirk_i82576_sriov);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x150a, quirk_i82576_sriov);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x150d, quirk_i82576_sriov);
#endif /* CONFIG_PCI_IOV */
^ permalink raw reply related
* Re: [PATCH 0/2] netxen: bug fixes
From: David Miller @ 2009-08-13 23:33 UTC (permalink / raw)
To: dhananjay; +Cc: davem, netdev
In-Reply-To: <1250182981-27594-1-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Thu, 13 Aug 2009 10:02:59 -0700
> 2 more fixes for 2.6.31. These will conflict with
> while merging with net-next-2.6 tree, will require
> simple manual merge.
Both applied to net-2.6, thanks.
^ permalink raw reply
* Re: [net-2.6 PATCH] ixgbe: fix issues setting rx-usecs with legacy interrupts
From: David Miller @ 2009-08-13 23:33 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, donald.skidmore
In-Reply-To: <20090811231805.13967.1829.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 11 Aug 2009 16:18:14 -0700
> From: Don Skidmore <donald.c.skidmore@intel.com>
>
> Currently setting rx-usecs when the interface is in legacy interrupt
> mode it is not immediate. We were only setting EITR for each MSIx
> vector and since this count would be zero for legacy mode it wasn't
> set until after a reset. This patch corrects that by checking what
> mode we are in and then setting EITR accordingly.
>
> Signed-off-by: Don Skidmore <donald.skidmore@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied to net-2.6
^ permalink raw reply
* Re: [PATCH 2.6.31-rc5] can: fix oops caused by wrong rtnl newlink usage
From: David Miller @ 2009-08-13 23:33 UTC (permalink / raw)
To: oliver; +Cc: kaber, wg, netdev, dbaryshkov
In-Reply-To: <4A8166F4.6040204@hartkopp.net>
From: Oliver Hartkopp <oliver@hartkopp.net>
Date: Tue, 11 Aug 2009 14:41:24 +0200
> For 'real' hardware CAN devices the netlink interface is used to set CAN
> specific communication parameters. Real CAN hardware can not be created with
> the ip tool ...
>
> The invocation of 'ip link add type can' lead to an oops as the standard rtnl
> newlink function was called:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=13954
>
> This patch adds a private newlink function for the CAN device driver interface
> that unconditionally returns -EOPNOTSUPP.
>
> Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
> Reported-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Applied to net-2.6
^ permalink raw reply
* Re: [RFC] ipv6: Change %pI6 format to output compacted addresses?
From: David Miller @ 2009-08-13 23:31 UTC (permalink / raw)
To: joe; +Cc: chuck.lever, brian.haley, jens, netdev
In-Reply-To: <1250198022.28285.133.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Thu, 13 Aug 2009 14:13:42 -0700
> On Thu, 2009-08-13 at 17:02 -0400, Chuck Lever wrote:
>> [ I would think user space in general should be using inet_pton(3)
>> everywhere for such interfaces, so the format of these addresses
>> wouldn't matter so much. Probably impossible at this point. ]
>
> David Miller is authoritative here.
In the final analysis, the risk is just too high to break
userspace. So let's play conservative here and not change
the output for currently user visible stuff.
^ permalink raw reply
* Re: [PATCH net-next-2.6] bonding: wipe out printk's
From: David Miller @ 2009-08-13 23:29 UTC (permalink / raw)
To: jpirko; +Cc: fubar, bonding-devel, netdev
In-Reply-To: <20090813141151.GA10449@psychotron.englab.brq.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Thu, 13 Aug 2009 16:11:52 +0200
> I did not introduce new lines over 80 chars. I even eliminated some of them.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Applied to net-next-2.6
^ 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