* Re: [PATCH 00/09] net: remove trailing spaces in messages
From: David Miller @ 2010-03-24 21:11 UTC (permalink / raw)
To: elendil
Cc: netdev, linux-kernel, per.liden, jon.maloy, allan.stephens,
samuel, benh, linuxppc-dev, e1000-devel
In-Reply-To: <201003241840.18701.elendil@planet.nl>
From: Frans Pop <elendil@planet.nl>
Date: Wed, 24 Mar 2010 18:40:15 +0100
> This is the second patchset to remove trailing spaces in kernel messages.
> Patches in this set cover networking code, excepting wireless which will be
> submitted in a separate set.
>
> Patches have been rebased against current net-next.
>
> Benefits are:
> - general cleanup and consistency
> - minor reduction in kernel size and user's log file size
> - reduced annoyance for people writing logcheck rules
>
> I have run the patches through checkpatch and included some fixes, but in
> most cases the files are so horrible in general that fixing the warnings
> purely for these changes doesn't make sense.
All applied, but I have to make some fixups.
For example, GIT warns about trailing whitespace on any lines that you
touched so I had to fix those up before putting them into the tree.
Thanks.
^ permalink raw reply
* [PATCH] xt_hashlimit: dl_seq_stop() fix
From: Eric Dumazet @ 2010-03-24 20:47 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David Miller, netdev, Netfilter Development Mailinglist
If dl_seq_start() memory allocation fails, we crash later in
dl_seq_stop(), trying to kfree(ERR_PTR(-ENOMEM))
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/netfilter/xt_hashlimit.c b/net/netfilter/xt_hashlimit.c
index 9e9c489..70d561a 100644
--- a/net/netfilter/xt_hashlimit.c
+++ b/net/netfilter/xt_hashlimit.c
@@ -879,7 +879,8 @@ static void dl_seq_stop(struct seq_file *s, void *v)
struct xt_hashlimit_htable *htable = s->private;
unsigned int *bucket = (unsigned int *)v;
- kfree(bucket);
+ if (!IS_ERR(bucket))
+ kfree(bucket);
spin_unlock_bh(&htable->lock);
}
^ permalink raw reply related
* Re: [patch] rds: cleanup: remove unneeded variable
From: David Miller @ 2010-03-24 20:37 UTC (permalink / raw)
To: error27
Cc: andy.grover, shemminger, adobriyan, eparis, rds-devel, netdev,
kernel-janitors
In-Reply-To: <20100324115730.GF21571@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Wed, 24 Mar 2010 14:57:30 +0300
> We never use "sk" so this patch removes it.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied, thanks Dan.
^ permalink raw reply
* Re: [patch] wimax: remove unneeded variable
From: David Miller @ 2010-03-24 20:36 UTC (permalink / raw)
To: error27; +Cc: netdev, andre.goddard, adobriyan, jkosina, kernel-janitors
In-Reply-To: <20100324115603.GD21571@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Wed, 24 Mar 2010 14:56:03 +0300
> We never actually use "dev" so I removed it.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
I think the intention was to pass it into to these
stupid function call tracing debugging macros the
WIMAX stuff has. It's passing NULL currently.
Anyways, I've applied this, thanks.
But seriously, why is every developer of some new subsystem or driver
inclined to add such ugly debugging infrastructure? It's seemingly
the first thing they do before writing any code.
I'd very much like to see a patch that removes all of this junk and
"rm -f include/linux/wimax/debug.h"
^ permalink raw reply
* Re: [PATCH 4/7] wireless/iwlwifi: remove trailing space in messages
From: reinette chatre @ 2010-03-24 20:34 UTC (permalink / raw)
To: Frans Pop
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Zhu, Yi, Intel Linux Wireless
In-Reply-To: <201003242128.18710.elendil@planet.nl>
On Wed, 2010-03-24 at 13:28 -0700, Frans Pop wrote:
> On Wednesday 24 March 2010, reinette chatre wrote:
> > Since this patch touches so many things, would it be possible to base
> > your patch on
> > git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6.git
> > instead?
>
> Sure. Which branch?
master
Thank you very much
Reinette
^ permalink raw reply
* Re: [patch] llc: cleanup: remove dead code from llc_init()
From: David Miller @ 2010-03-24 20:34 UTC (permalink / raw)
To: acme; +Cc: error27, opurdila, netdev, kernel-janitors
In-Reply-To: <20100324135418.GD23594@ghostprotocols.net>
From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Date: Wed, 24 Mar 2010 10:54:18 -0300
> Em Wed, Mar 24, 2010 at 02:55:10PM +0300, Dan Carpenter escreveu:
>> We don't need "dev" any more after:
>> a5a04819c5740cb1aa217af2cc8f5ef26f33d744
>> [LLC]: station source mac address
>>
>> Signed-off-by: Dan Carpenter <error27@gmail.com>
>
> Old leftovers, well spotted, Dave, please apply.
>
>
> Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 4/7] wireless/iwlwifi: remove trailing space in messages
From: Frans Pop @ 2010-03-24 20:28 UTC (permalink / raw)
To: reinette chatre
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Zhu, Yi, Intel Linux Wireless
In-Reply-To: <1269461933.2446.3208.camel@rchatre-DESK>
On Wednesday 24 March 2010, reinette chatre wrote:
> Since this patch touches so many things, would it be possible to base
> your patch on
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6.git
> instead?
Sure. Which branch?
^ permalink raw reply
* Re: [patch] af_key: return error if pfkey_xfrm_policy2msg_prep() fails
From: David Miller @ 2010-03-24 20:28 UTC (permalink / raw)
To: hadi; +Cc: error27, netdev, eric.dumazet, shemminger, adobriyan,
kernel-janitors
In-Reply-To: <1269448790.4089.34.camel@bigi>
From: jamal <hadi@cyberus.ca>
Date: Wed, 24 Mar 2010 12:39:50 -0400
> I am really sorry - your patch is pfkey path and the example i gave you
> is xfrm based;-< I worry too much, so never mind - the change seems
> harmless enough:
> Acked-by: Jamal Hadi Salim <hadi@mojatatu.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH 2/2] ipv4: Restart rt_intern_hash after emergency rebuild
From: Neil Horman @ 2010-03-24 20:21 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: David Miller, Eric Dumazet, Linux Netdev List
In-Reply-To: <4BAA4F3F.70703@openvz.org>
On Wed, Mar 24, 2010 at 08:43:27PM +0300, Pavel Emelyanov wrote:
> The the rebuild changes the genid which in turn is used at the
> hash calculation. Thus if we don't restart and go on with the
> inserting the rt will happen in wrong chain.
>
> This doesn't seem critical to me, since the proper rt entry will
> be hashed at next skb.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
> ---
> net/ipv4/route.c | 18 ++++++++++++------
> 1 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 28c1c2f..bbce53e 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -1097,7 +1097,7 @@ static int slow_chain_length(const struct rtable *head)
> }
>
> static int rt_intern_hash(unsigned hash, struct rtable *rt,
> - struct rtable **rp, struct sk_buff *skb)
> + struct rtable **rp, struct sk_buff *skb, int in)
> {
> struct rtable *rth, **rthp;
> unsigned long now;
> @@ -1217,6 +1217,12 @@ restart:
> rt->u.dst.dev->name, num);
> }
> rt_emergency_hash_rebuild(net);
> + spin_unlock_bh(rt_hash_lock_addr(hash));
> +
> + hash = rt_hash(rt->fl.fl4_dst, rt->fl.fl4_src,
> + in ? rt->fl.iif : rt->fl.oif,
> + rt_genid(net));
> + goto restart;
> }
> }
Why pass in a flag here? Perhaps it would be easier just to pass in the ifindex
that was origionally used by the caller of rt_intern_hash so that the hash could
be redone without needing to toggle on the value of the flag.
Regards
Neil
>
^ permalink raw reply
* Re: [RFC PATCH] gianfar: fix undo of reserve()
From: David Miller @ 2010-03-24 20:21 UTC (permalink / raw)
To: ben; +Cc: netdev
In-Reply-To: <A6A1774AFD79E346AE6D49A33CB294530DC1A006@EX-BE-017-SFO.shared.themessagecenter.com>
From: "Ben Menchaca (ben@bigfootnetworks.com)" <ben@bigfootnetworks.com>
Date: Wed, 24 Mar 2010 13:13:22 -0700
> I would definitely prefer getting some modern-ish kernel time on it.
> If needed, I can probably move our board forward to -next for a bit.
If anyone can test this on a current kernel that would be
enough for me.
^ permalink raw reply
* Re: [PATCH 4/7] wireless/iwlwifi: remove trailing space in messages
From: reinette chatre @ 2010-03-24 20:18 UTC (permalink / raw)
To: Frans Pop
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Zhu, Yi, Intel Linux Wireless
In-Reply-To: <1269456395-15343-4-git-send-email-elendil@planet.nl>
Hi Frans,
On Wed, 2010-03-24 at 11:46 -0700, Frans Pop wrote:
> Includes minor improvements in debugging messages in iwl-4965.c,
> function iwl4965_is_temp_calib_needed().
>
> Signed-off-by: Frans Pop <elendil@planet.nl>
> Cc: Zhu Yi <yi.zhu@intel.com>
> Cc: Reinette Chatre <reinette.chatre@intel.com>
> Cc: Intel Linux Wireless <ilw@linux.intel.com>
>
> wireless/intel
Since this patch touches so many things, would it be possible to base
your patch on
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6.git
instead? We currently have some code reorganization pending there that
is undergoing validation before we push it upstream. If you do so you
can send the patch to me indicating so and I will push it upstream as
part of our process to ensure there are no conflicts ahead.
Thank you
Reinette
^ permalink raw reply
* RE: [RFC PATCH] gianfar: fix undo of reserve()
From: Ben Menchaca (ben@bigfootnetworks.com) @ 2010-03-24 20:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20100324.114759.200629461.davem@davemloft.net>
> So, is this tested at least a little bit?
We run a 2.6.31 variant on our board, and this patch fixes the skb->len issue, and we are not observing any strangeness under the stress conditions after this patch, and our asserts are no longer firing. 2.6.31 was pre-multiq for gianfar, though, and that was a large change...I would definitely prefer getting some modern-ish kernel time on it. If needed, I can probably move our board forward to -next for a bit.
For some history, and to see the original issue addressed, this appears to have been introduced shortly after recycling in 2.6.30, here:
commit d4a76f8a619b5d7dfd5a0f122666fee24bb3dcb9
gianfar: fix BUG under load after introduction of skb recycling
- Ben
^ permalink raw reply
* Re: [net-2.6 PATCH] ixgbe: cleanup maximum number of tx queues
From: Eric Dumazet @ 2010-03-24 20:08 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, gospo, John Fastabend
In-Reply-To: <20100324200144.6384.17291.stgit@localhost.localdomain>
Le mercredi 24 mars 2010 à 13:01 -0700, Jeff Kirsher a écrit :
> From: John Fastabend <john.r.fastabend@intel.com>
>
> In the last patch I missed an unecessary min_t comparison.
> This patch removes it, the path allocates at most
> 72 tx queues for 82599 and 24 for 82598 there is no need
> for this check.
>
> Additionally this sets MAX_[TX|RX]_QUEUES to 72. Which is
> used as the size for the tx/rx_ring arrays. There is no
> reason to have more tx_rings/rx_rings then num_tx_queues.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Thanks guys
> ---
>
> drivers/net/ixgbe/ixgbe.h | 7 +++++--
> drivers/net/ixgbe/ixgbe_main.c | 1 -
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe.h b/drivers/net/ixgbe/ixgbe.h
> index 19e94ee..79c35ae 100644
> --- a/drivers/net/ixgbe/ixgbe.h
> +++ b/drivers/net/ixgbe/ixgbe.h
> @@ -204,14 +204,17 @@ enum ixgbe_ring_f_enum {
> #define IXGBE_MAX_FDIR_INDICES 64
> #ifdef IXGBE_FCOE
> #define IXGBE_MAX_FCOE_INDICES 8
> +#define MAX_RX_QUEUES (IXGBE_MAX_FDIR_INDICES + IXGBE_MAX_FCOE_INDICES)
> +#define MAX_TX_QUEUES (IXGBE_MAX_FDIR_INDICES + IXGBE_MAX_FCOE_INDICES)
> +#else
> +#define MAX_RX_QUEUES IXGBE_MAX_FDIR_INDICES
> +#define MAX_TX_QUEUES IXGBE_MAX_FDIR_INDICES
> #endif /* IXGBE_FCOE */
> struct ixgbe_ring_feature {
> int indices;
> int mask;
> } ____cacheline_internodealigned_in_smp;
>
> -#define MAX_RX_QUEUES 128
> -#define MAX_TX_QUEUES 128
>
> #define MAX_RX_PACKET_BUFFERS ((adapter->flags & IXGBE_FLAG_DCB_ENABLED) \
> ? 8 : 1)
> diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
> index 315622f..a9147e5 100644
> --- a/drivers/net/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ixgbe/ixgbe_main.c
> @@ -6041,7 +6041,6 @@ static int __devinit ixgbe_probe(struct pci_dev *pdev,
> indices += min_t(unsigned int, num_possible_cpus(),
> IXGBE_MAX_FCOE_INDICES);
> #endif
> - indices = min_t(unsigned int, indices, MAX_TX_QUEUES);
> netdev = alloc_etherdev_mq(sizeof(struct ixgbe_adapter), indices);
> if (!netdev) {
> err = -ENOMEM;
>
> --
^ permalink raw reply
* [net-2.6 PATCH] ixgbe: Don't allow user buffer count to exceed 256
From: Jeff Kirsher @ 2010-03-24 20:02 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Robert Love, Yi Zou, Frank Zhang, Jeff Kirsher
From: Robert Love <robert.w.love@intel.com>
If the user buffer count was 256 the shift would place a 1
in the offset region leading to errors. It also overwrites
the uers buffer list. This patch makes sure that at most
256 user buffers are allowed for DDP and the buffer count
is masked properly such that it doesn't overwrite the offset
when shifting the bits.
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: Yi Zou <yi.zou@intel.com>
Signed-off-by: Frank Zhang <frank_1.zhang@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_fcoe.c | 18 ++++++++++--------
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_fcoe.c b/drivers/net/ixgbe/ixgbe_fcoe.c
index 700cfc0..e1978da 100644
--- a/drivers/net/ixgbe/ixgbe_fcoe.c
+++ b/drivers/net/ixgbe/ixgbe_fcoe.c
@@ -202,6 +202,15 @@ int ixgbe_fcoe_ddp_get(struct net_device *netdev, u16 xid,
addr = sg_dma_address(sg);
len = sg_dma_len(sg);
while (len) {
+ /* max number of buffers allowed in one DDP context */
+ if (j >= IXGBE_BUFFCNT_MAX) {
+ netif_err(adapter, drv, adapter->netdev,
+ "xid=%x:%d,%d,%d:addr=%llx "
+ "not enough descriptors\n",
+ xid, i, j, dmacount, (u64)addr);
+ goto out_noddp_free;
+ }
+
/* get the offset of length of current buffer */
thisoff = addr & ((dma_addr_t)bufflen - 1);
thislen = min((bufflen - thisoff), len);
@@ -227,20 +236,13 @@ int ixgbe_fcoe_ddp_get(struct net_device *netdev, u16 xid,
len -= thislen;
addr += thislen;
j++;
- /* max number of buffers allowed in one DDP context */
- if (j > IXGBE_BUFFCNT_MAX) {
- DPRINTK(DRV, ERR, "xid=%x:%d,%d,%d:addr=%llx "
- "not enough descriptors\n",
- xid, i, j, dmacount, (u64)addr);
- goto out_noddp_free;
- }
}
}
/* only the last buffer may have non-full bufflen */
lastsize = thisoff + thislen;
fcbuff = (IXGBE_FCBUFF_4KB << IXGBE_FCBUFF_BUFFSIZE_SHIFT);
- fcbuff |= (j << IXGBE_FCBUFF_BUFFCNT_SHIFT);
+ fcbuff |= ((j & 0xff) << IXGBE_FCBUFF_BUFFCNT_SHIFT);
fcbuff |= (firstoff << IXGBE_FCBUFF_OFFSET_SHIFT);
fcbuff |= (IXGBE_FCBUFF_VALID);
^ permalink raw reply related
* [net-2.6 PATCH] ixgbe: cleanup maximum number of tx queues
From: Jeff Kirsher @ 2010-03-24 20:01 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, John Fastabend, Jeff Kirsher
From: John Fastabend <john.r.fastabend@intel.com>
In the last patch I missed an unecessary min_t comparison.
This patch removes it, the path allocates at most
72 tx queues for 82599 and 24 for 82598 there is no need
for this check.
Additionally this sets MAX_[TX|RX]_QUEUES to 72. Which is
used as the size for the tx/rx_ring arrays. There is no
reason to have more tx_rings/rx_rings then num_tx_queues.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe.h | 7 +++++--
drivers/net/ixgbe/ixgbe_main.c | 1 -
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe.h b/drivers/net/ixgbe/ixgbe.h
index 19e94ee..79c35ae 100644
--- a/drivers/net/ixgbe/ixgbe.h
+++ b/drivers/net/ixgbe/ixgbe.h
@@ -204,14 +204,17 @@ enum ixgbe_ring_f_enum {
#define IXGBE_MAX_FDIR_INDICES 64
#ifdef IXGBE_FCOE
#define IXGBE_MAX_FCOE_INDICES 8
+#define MAX_RX_QUEUES (IXGBE_MAX_FDIR_INDICES + IXGBE_MAX_FCOE_INDICES)
+#define MAX_TX_QUEUES (IXGBE_MAX_FDIR_INDICES + IXGBE_MAX_FCOE_INDICES)
+#else
+#define MAX_RX_QUEUES IXGBE_MAX_FDIR_INDICES
+#define MAX_TX_QUEUES IXGBE_MAX_FDIR_INDICES
#endif /* IXGBE_FCOE */
struct ixgbe_ring_feature {
int indices;
int mask;
} ____cacheline_internodealigned_in_smp;
-#define MAX_RX_QUEUES 128
-#define MAX_TX_QUEUES 128
#define MAX_RX_PACKET_BUFFERS ((adapter->flags & IXGBE_FLAG_DCB_ENABLED) \
? 8 : 1)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 315622f..a9147e5 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -6041,7 +6041,6 @@ static int __devinit ixgbe_probe(struct pci_dev *pdev,
indices += min_t(unsigned int, num_possible_cpus(),
IXGBE_MAX_FCOE_INDICES);
#endif
- indices = min_t(unsigned int, indices, MAX_TX_QUEUES);
netdev = alloc_etherdev_mq(sizeof(struct ixgbe_adapter), indices);
if (!netdev) {
err = -ENOMEM;
^ permalink raw reply related
* Re: behavior of recvmmsg() on blocking sockets
From: Brandon Black @ 2010-03-24 19:55 UTC (permalink / raw)
To: Chris Friesen; +Cc: linux-kernel, netdev
In-Reply-To: <4BAA69BF.3080600@nortel.com>
On Wed, Mar 24, 2010 at 2:36 PM, Chris Friesen <cfriesen@nortel.com> wrote:
> Note that I said "large numbers of sockets". Like tens of thousands.
> In addition to context switch overhead this can also lead to issues with
> memory consumption due to stack frames.
Ok, agreed there. In my case though, there will only ever be a
handful of sockets. Ideally it would be just one socket. The only
reason I allocate multiple sockets and spawn threads for them is
because you can't scale past one CPU core on a single socket, due to
the NIC and/or the driver and/or the socket locks and/or the basic
nature of the problem.
> Consider the case where you want to do some other useful work in
> addition to running your network server. Every cpu cycle spent on the
> network server is robbed from the other work. In this scenario you want
> to handle packets as efficiently as possible, so the timeout-based
> behaviour is better since it is more likely to give you multiple packets
> per syscall.
That's a good point, I tend to tunnelvision on the dedicated server
scenario. I should probably have a user-level option for
timeout-based operation as well, since the decision here gets to the
systems admin/engineering level and will be situational.
Thanks,
-- Brandon
^ permalink raw reply
* Re: bug in bonding driver
From: Chris Friesen @ 2010-03-24 19:47 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev, bonding-devel
In-Reply-To: <21160.1269458000@death.nxdomain.ibm.com>
On 03/24/2010 01:13 PM, Jay Vosburgh wrote:
> Chris Friesen <cfriesen@nortel.com> wrote:
>> The catch here is that slave->jiffies may not ever get updated after
>> being set initially, and on long-running systems jiffies will overflow.
>> That could cause this check to be true for a substantial amount of time
>> rather than for just a short period.
> Some quick fooling around suggests that if, for example,
> slave->jiffies is near the top of the range (ULONG_MAX - a few hundred),
> when jiffies gets up to around ULONG_MAX / 2 time_after_eq will flip
> from "after" to "before."
>
> I don't think this is a particularly farfetched example, since
> jiffies is intentionally started near the top of the range, so
> slave->jiffies is likely to be high in the range after bonding is
> configured at boot.
Agreed. If I understand it right the result of time_after_eq is only
valid if the result of the subtraction is less than LONG_MAX.
>> One way to fix it would be a boolean which tracks whether or not we've
>> gone past the time, and if we have then we don't bother actually
>> checking the time anymore.
>
> It might be clearer to make the slave->jiffies some kind of
> countdown instead, perhaps reusing the slave->delay used for
> updelay/downdelay and eliminating slave->jiffies entirely.
Yes, that seems reasonable as well.
Chris
^ permalink raw reply
* [net-2.6 PATCH 2/3] ixgbe: In SR-IOV mode insert delay before bring the adapter up
From: Jeff Kirsher @ 2010-03-24 19:36 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Greg Rose, Jeff Kirsher
In-Reply-To: <20100324193515.6078.27035.stgit@localhost.localdomain>
From: Greg Rose <gregory.v.rose@intel.com>
VFs running in guest VMs do not respond in as timely a manner to
PF indication it is going down as they do when running in the host
domain. If the adapter is in SR-IOV mode insert a two second delay
to guarantee that all VFs have had time to respond to the PF reset.
In any case resetting the PF while VFs are active should be
discouraged but if it must be done then there will be a two
second delay to help synchronize resets among the PF and all the
VFs.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 90565d8..2f8c348 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -3036,6 +3036,14 @@ void ixgbe_reinit_locked(struct ixgbe_adapter *adapter)
while (test_and_set_bit(__IXGBE_RESETTING, &adapter->state))
msleep(1);
ixgbe_down(adapter);
+ /*
+ * If SR-IOV enabled then wait a bit before bringing the adapter
+ * back up to give the VFs time to respond to the reset. The
+ * two second wait is based upon the watchdog timer cycle in
+ * the VF driver.
+ */
+ if (adapter->flags & IXGBE_FLAG_SRIOV_ENABLED)
+ msleep(2000);
ixgbe_up(adapter);
clear_bit(__IXGBE_RESETTING, &adapter->state);
}
^ permalink raw reply related
* [net-2.6 PATCH 3/3] ixgbe: Change where clear_to_send_flag is reset to zero.
From: Jeff Kirsher @ 2010-03-24 19:36 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Greg Rose, Jeff Kirsher
In-Reply-To: <20100324193515.6078.27035.stgit@localhost.localdomain>
From: Greg Rose <gregory.v.rose@intel.com>
The clear_to_send flag is being cleared before the call to ping all
the VFs. It should be called after pinging all the VFs.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 2f8c348..315622f 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -3224,13 +3224,15 @@ void ixgbe_down(struct ixgbe_adapter *adapter)
/* disable receive for all VFs and wait one second */
if (adapter->num_vfs) {
- for (i = 0 ; i < adapter->num_vfs; i++)
- adapter->vfinfo[i].clear_to_send = 0;
-
/* ping all the active vfs to let them know we are going down */
ixgbe_ping_all_vfs(adapter);
+
/* Disable all VFTE/VFRE TX/RX */
ixgbe_disable_tx_rx(adapter);
+
+ /* Mark all the VFs as inactive */
+ for (i = 0 ; i < adapter->num_vfs; i++)
+ adapter->vfinfo[i].clear_to_send = 0;
}
/* disable receives */
^ permalink raw reply related
* Re: behavior of recvmmsg() on blocking sockets
From: Chris Friesen @ 2010-03-24 19:36 UTC (permalink / raw)
To: Brandon Black; +Cc: linux-kernel, netdev
In-Reply-To: <84621a61003241128x3afbcea1w387aeaa68c887320@mail.gmail.com>
On 03/24/2010 12:28 PM, Brandon Black wrote:
> On Wed, Mar 24, 2010 at 12:41 PM, Chris Friesen <cfriesen@nortel.com> wrote:
>> On 03/24/2010 10:15 AM, Brandon Black wrote:
>>> It uses a thread-per-socket model
>>
>> This doesn't scale well to large numbers of sockets....you get a lot of
>> unnecessary context switching.
>
> It scales great actually, within my measurement error of linear in
> testing so far. These are UDP server sockets, and the traffic pattern
> is one request packet maps to one response packet, with no longer-term
> per-client state (this is a DNS server, to be specific). The "do some
> work" code doesn't have any inter-thread contention (no locks, no
> writes to the same memory, etc), so the "threads" here may as well be
> processes if that makes the discussion less confusing. I haven't yet
> found a model that scales as well for me.
Note that I said "large numbers of sockets". Like tens of thousands.
In addition to context switch overhead this can also lead to issues with
memory consumption due to stack frames.
> I'm also just not personally sure whether there are network
> interfaces/drivers out there that could queue packets to the kernel
> (to a single socket) faster than recvmsg() could dequeue them to
> userspace
A 10Gig NIC could do this easily depending on your CPU.
> I still think having a "block until at least one packet arrives" mode
> for recvmmsg() makes sense though.
Agreed, as long as developers are aware that it won't be the most
efficient mode of operation.
Consider the case where you want to do some other useful work in
addition to running your network server. Every cpu cycle spent on the
network server is robbed from the other work. In this scenario you want
to handle packets as efficiently as possible, so the timeout-based
behaviour is better since it is more likely to give you multiple packets
per syscall.
Chris
^ permalink raw reply
* [net-2.6 PATCH 1/3] ixgbevf: Fix signed/unsigned int error
From: Jeff Kirsher @ 2010-03-24 19:35 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Greg Rose, Jeff Kirsher
From: Greg Rose <gregory.v.rose@intel.com>
In the Tx mapping function if a DMA error occurred then the unwind of
previously mapped sections would improperly check an unsigned int if
it was less than zero. Changed the index variable to signed to avoid
the error.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbevf/ixgbevf_main.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ixgbevf/ixgbevf_main.c b/drivers/net/ixgbevf/ixgbevf_main.c
index 9aaebd3..55f74b3 100644
--- a/drivers/net/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ixgbevf/ixgbevf_main.c
@@ -2921,9 +2921,10 @@ static int ixgbevf_tx_map(struct ixgbevf_adapter *adapter,
struct ixgbevf_tx_buffer *tx_buffer_info;
unsigned int len;
unsigned int total = skb->len;
- unsigned int offset = 0, size, count = 0, i;
+ unsigned int offset = 0, size, count = 0;
unsigned int nr_frags = skb_shinfo(skb)->nr_frags;
unsigned int f;
+ int i;
i = tx_ring->next_to_use;
^ permalink raw reply related
* RE: [PATCH 00/09] net: remove trailing spaces in messages
From: Jon Maloy @ 2010-03-24 19:31 UTC (permalink / raw)
To: David Miller, elendil@planet.nl; +Cc: netdev@vger.kernel.org
In-Reply-To: <20100324.114318.102672043.davem@davemloft.net>
You'll have it shortly, as I just told Frans.
I don't have access to my environment where I am right now.
///jon
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: March-24-10 14:43
> To: elendil@planet.nl
> Cc: netdev@vger.kernel.org; Jon Maloy
> Subject: Re: [PATCH 00/09] net: remove trailing spaces in messages
>
> From: Frans Pop <elendil@planet.nl>
> Date: Wed, 24 Mar 2010 19:05:09 +0100
>
> > The address for Per Linden listed in MAINTAINERS for "TIPC
> NETWORK LAYER"
> > appears no longer to be valid.
> >
> > Maybe it can be updated or removed?
>
> I'm happy to apply that patch, please send it :-)
>
^ permalink raw reply
* Re: bug in bonding driver
From: Jay Vosburgh @ 2010-03-24 19:13 UTC (permalink / raw)
To: Chris Friesen; +Cc: netdev, bonding-devel
In-Reply-To: <4BAA58B3.2040504@nortel.com>
Chris Friesen <cfriesen@nortel.com> wrote:
>One of our guys pointed out what appears to be a bug in
>bond_ab_arp_inspect(). There's a chunk of code that looks like this:
>
> /*
> * Give slaves 2*delta after being enslaved or made
> * active. This avoids bouncing, as the last receive
> * times need a full ARP monitor cycle to be updated.
> */
> if (!time_after_eq(jiffies, slave->jiffies +
> 2 * delta_in_ticks))
> continue;
>
>The catch here is that slave->jiffies may not ever get updated after
>being set initially, and on long-running systems jiffies will overflow.
> That could cause this check to be true for a substantial amount of time
>rather than for just a short period.
The definition for time_after in include/linux/jiffies.h claims
to handle timer wrapping, but even so, there presumably has to be a
cutoff at which "after" becomes "before" again.
Some quick fooling around suggests that if, for example,
slave->jiffies is near the top of the range (ULONG_MAX - a few hundred),
when jiffies gets up to around ULONG_MAX / 2 time_after_eq will flip
from "after" to "before."
I don't think this is a particularly farfetched example, since
jiffies is intentionally started near the top of the range, so
slave->jiffies is likely to be high in the range after bonding is
configured at boot.
>One way to fix it would be a boolean which tracks whether or not we've
>gone past the time, and if we have then we don't bother actually
>checking the time anymore.
It might be clearer to make the slave->jiffies some kind of
countdown instead, perhaps reusing the slave->delay used for
updelay/downdelay and eliminating slave->jiffies entirely.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH 2/7] wireless/ath: remove trailing space in messages
From: Luis R. Rodriguez @ 2010-03-24 18:52 UTC (permalink / raw)
To: Frans Pop
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Luis Rodriguez
In-Reply-To: <1269456395-15343-2-git-send-email-elendil@planet.nl>
On Wed, Mar 24, 2010 at 11:46:30AM -0700, Frans Pop wrote:
> Signed-off-by: Frans Pop <elendil@planet.nl>
> Cc: Luis R. Rodriguez <lrodriguez@atheros.com>
thanks but not right now, we have some patches pending which would interference with this.
Luis
^ permalink raw reply
* [PATCH 5/7] wireless/prism54: remove trailing space in messages
From: Frans Pop @ 2010-03-24 18:46 UTC (permalink / raw)
To: linux-wireless, netdev, linux-kernel; +Cc: Frans Pop, Luis R. Rodriguez
In-Reply-To: <201003241927.12434.elendil@planet.nl>
Signed-off-by: Frans Pop <elendil@planet.nl>
Cc: Luis R. Rodriguez <mcgrof@gmail.com>
---
drivers/net/wireless/p54/txrx.c | 2 +-
drivers/net/wireless/prism54/islpci_dev.c | 16 ++++++++--------
drivers/net/wireless/prism54/islpci_eth.c | 8 ++++----
drivers/net/wireless/prism54/islpci_mgt.c | 8 ++++----
drivers/net/wireless/prism54/oid_mgt.c | 2 +-
5 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/net/wireless/p54/txrx.c b/drivers/net/wireless/p54/txrx.c
index 6605799..2ceff54 100644
--- a/drivers/net/wireless/p54/txrx.c
+++ b/drivers/net/wireless/p54/txrx.c
@@ -38,7 +38,7 @@ static void p54_dump_tx_queue(struct p54_common *priv)
u32 largest_hole = 0, free;
spin_lock_irqsave(&priv->tx_queue.lock, flags);
- printk(KERN_DEBUG "%s: / --- tx queue dump (%d entries) --- \n",
+ printk(KERN_DEBUG "%s: / --- tx queue dump (%d entries) ---\n",
wiphy_name(priv->hw->wiphy), skb_queue_len(&priv->tx_queue));
prev_addr = priv->rx_start;
diff --git a/drivers/net/wireless/prism54/islpci_dev.c b/drivers/net/wireless/prism54/islpci_dev.c
index a3ba353..7c82e43 100644
--- a/drivers/net/wireless/prism54/islpci_dev.c
+++ b/drivers/net/wireless/prism54/islpci_dev.c
@@ -227,14 +227,14 @@ islpci_interrupt(int irq, void *config)
#if VERBOSE > SHOW_ERROR_MESSAGES
DEBUG(SHOW_FUNCTION_CALLS,
- "IRQ: Identification register 0x%p 0x%x \n", device, reg);
+ "IRQ: Identification register 0x%p 0x%x\n", device, reg);
#endif
/* check for each bit in the register separately */
if (reg & ISL38XX_INT_IDENT_UPDATE) {
#if VERBOSE > SHOW_ERROR_MESSAGES
/* Queue has been updated */
- DEBUG(SHOW_TRACING, "IRQ: Update flag \n");
+ DEBUG(SHOW_TRACING, "IRQ: Update flag\n");
DEBUG(SHOW_QUEUE_INDEXES,
"CB drv Qs: [%i][%i][%i][%i][%i][%i]\n",
@@ -300,7 +300,7 @@ islpci_interrupt(int irq, void *config)
ISL38XX_CB_RX_DATA_LQ) != 0) {
#if VERBOSE > SHOW_ERROR_MESSAGES
DEBUG(SHOW_TRACING,
- "Received frame in Data Low Queue \n");
+ "Received frame in Data Low Queue\n");
#endif
islpci_eth_receive(priv);
}
@@ -325,7 +325,7 @@ islpci_interrupt(int irq, void *config)
/* Device has been initialized */
#if VERBOSE > SHOW_ERROR_MESSAGES
DEBUG(SHOW_TRACING,
- "IRQ: Init flag, device initialized \n");
+ "IRQ: Init flag, device initialized\n");
#endif
wake_up(&priv->reset_done);
}
@@ -333,7 +333,7 @@ islpci_interrupt(int irq, void *config)
if (reg & ISL38XX_INT_IDENT_SLEEP) {
/* Device intends to move to powersave state */
#if VERBOSE > SHOW_ERROR_MESSAGES
- DEBUG(SHOW_TRACING, "IRQ: Sleep flag \n");
+ DEBUG(SHOW_TRACING, "IRQ: Sleep flag\n");
#endif
isl38xx_handle_sleep_request(priv->control_block,
&powerstate,
@@ -343,7 +343,7 @@ islpci_interrupt(int irq, void *config)
if (reg & ISL38XX_INT_IDENT_WAKEUP) {
/* Device has been woken up to active state */
#if VERBOSE > SHOW_ERROR_MESSAGES
- DEBUG(SHOW_TRACING, "IRQ: Wakeup flag \n");
+ DEBUG(SHOW_TRACING, "IRQ: Wakeup flag\n");
#endif
isl38xx_handle_wakeup(priv->control_block,
@@ -634,7 +634,7 @@ islpci_alloc_memory(islpci_private *priv)
ioremap(pci_resource_start(priv->pdev, 0),
ISL38XX_PCI_MEM_SIZE))) {
/* error in remapping the PCI device memory address range */
- printk(KERN_ERR "PCI memory remapping failed \n");
+ printk(KERN_ERR "PCI memory remapping failed\n");
return -1;
}
@@ -901,7 +901,7 @@ islpci_setup(struct pci_dev *pdev)
if (register_netdev(ndev)) {
DEBUG(SHOW_ERROR_MESSAGES,
- "ERROR: register_netdev() failed \n");
+ "ERROR: register_netdev() failed\n");
goto do_islpci_free_memory;
}
diff --git a/drivers/net/wireless/prism54/islpci_eth.c b/drivers/net/wireless/prism54/islpci_eth.c
index 872b647..af9e7fb 100644
--- a/drivers/net/wireless/prism54/islpci_eth.c
+++ b/drivers/net/wireless/prism54/islpci_eth.c
@@ -89,7 +89,7 @@ islpci_eth_transmit(struct sk_buff *skb, struct net_device *ndev)
u32 curr_frag;
#if VERBOSE > SHOW_ERROR_MESSAGES
- DEBUG(SHOW_FUNCTION_CALLS, "islpci_eth_transmit \n");
+ DEBUG(SHOW_FUNCTION_CALLS, "islpci_eth_transmit\n");
#endif
/* lock the driver code */
@@ -140,7 +140,7 @@ islpci_eth_transmit(struct sk_buff *skb, struct net_device *ndev)
}
#if VERBOSE > SHOW_ERROR_MESSAGES
- DEBUG(SHOW_TRACING, "memmove %p %p %i \n", skb->data,
+ DEBUG(SHOW_TRACING, "memmove %p %p %i\n", skb->data,
src, skb->len);
#endif
} else {
@@ -319,7 +319,7 @@ islpci_eth_receive(islpci_private *priv)
int discard = 0;
#if VERBOSE > SHOW_ERROR_MESSAGES
- DEBUG(SHOW_FUNCTION_CALLS, "islpci_eth_receive \n");
+ DEBUG(SHOW_FUNCTION_CALLS, "islpci_eth_receive\n");
#endif
/* the device has written an Ethernet frame in the data area
@@ -431,7 +431,7 @@ islpci_eth_receive(islpci_private *priv)
skb = dev_alloc_skb(MAX_FRAGMENT_SIZE_RX + 2);
if (unlikely(skb == NULL)) {
/* error allocating an sk_buff structure elements */
- DEBUG(SHOW_ERROR_MESSAGES, "Error allocating skb \n");
+ DEBUG(SHOW_ERROR_MESSAGES, "Error allocating skb\n");
break;
}
skb_reserve(skb, (4 - (long) skb->data) & 0x03);
diff --git a/drivers/net/wireless/prism54/islpci_mgt.c b/drivers/net/wireless/prism54/islpci_mgt.c
index 69d2f88..89b0278 100644
--- a/drivers/net/wireless/prism54/islpci_mgt.c
+++ b/drivers/net/wireless/prism54/islpci_mgt.c
@@ -113,7 +113,7 @@ islpci_mgmt_rx_fill(struct net_device *ndev)
u32 curr = le32_to_cpu(cb->driver_curr_frag[ISL38XX_CB_RX_MGMTQ]);
#if VERBOSE > SHOW_ERROR_MESSAGES
- DEBUG(SHOW_FUNCTION_CALLS, "islpci_mgmt_rx_fill \n");
+ DEBUG(SHOW_FUNCTION_CALLS, "islpci_mgmt_rx_fill\n");
#endif
while (curr - priv->index_mgmt_rx < ISL38XX_CB_MGMT_QSIZE) {
@@ -211,7 +211,7 @@ islpci_mgt_transmit(struct net_device *ndev, int operation, unsigned long oid,
{
pimfor_header_t *h = buf.mem;
DEBUG(SHOW_PIMFOR_FRAMES,
- "PIMFOR: op %i, oid 0x%08lx, device %i, flags 0x%x length 0x%x \n",
+ "PIMFOR: op %i, oid 0x%08lx, device %i, flags 0x%x length 0x%x\n",
h->operation, oid, h->device_id, h->flags, length);
/* display the buffer contents for debugging */
@@ -279,7 +279,7 @@ islpci_mgt_receive(struct net_device *ndev)
u32 curr_frag;
#if VERBOSE > SHOW_ERROR_MESSAGES
- DEBUG(SHOW_FUNCTION_CALLS, "islpci_mgt_receive \n");
+ DEBUG(SHOW_FUNCTION_CALLS, "islpci_mgt_receive\n");
#endif
/* Only once per interrupt, determine fragment range to
@@ -338,7 +338,7 @@ islpci_mgt_receive(struct net_device *ndev)
#if VERBOSE > SHOW_ERROR_MESSAGES
DEBUG(SHOW_PIMFOR_FRAMES,
- "PIMFOR: op %i, oid 0x%08x, device %i, flags 0x%x length 0x%x \n",
+ "PIMFOR: op %i, oid 0x%08x, device %i, flags 0x%x length 0x%x\n",
header->operation, header->oid, header->device_id,
header->flags, header->length);
diff --git a/drivers/net/wireless/prism54/oid_mgt.c b/drivers/net/wireless/prism54/oid_mgt.c
index 1187e61..07df70a 100644
--- a/drivers/net/wireless/prism54/oid_mgt.c
+++ b/drivers/net/wireless/prism54/oid_mgt.c
@@ -819,7 +819,7 @@ mgt_response_to_str(enum oid_num_t n, union oid_res_t *r, char *str)
k = snprintf(str, PRIV_STR_SIZE, "nr=%u\n", list->nr);
for (i = 0; i < list->nr; i++)
k += snprintf(str + k, PRIV_STR_SIZE - k,
- "bss[%u] : \nage=%u\nchannel=%u\n"
+ "bss[%u] :\nage=%u\nchannel=%u\n"
"capinfo=0x%X\nrates=0x%X\n"
"basic_rates=0x%X\n",
i, list->bsslist[i].age,
--
1.6.6.1
^ permalink raw reply related
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