* Re: [RFC PATCH] sched: Fix resource limiting in pfifo_fast
From: Jarek Poplawski @ 2009-08-30 9:57 UTC (permalink / raw)
To: Krishna Kumar2; +Cc: davem, Eric Dumazet, netdev
In-Reply-To: <OFCC154671.89248E03-ON65257622.002DFE20-65257622.00302D56@in.ibm.com>
On Sun, Aug 30, 2009 at 02:16:13PM +0530, Krishna Kumar2 wrote:
> > Jarek Poplawski <jarkao2@gmail.com>
> > >> pfifo_fast_enqueue has this check:
> > >> if (skb_queue_len(list) < qdisc_dev(qdisc)->tx_queue_len) {
> > >>
> > >> which allows each band to enqueue upto tx_queue_len skbs for a
> > >> total of 3*tx_queue_len skbs. I am not sure if this was the
> > >> intention of limiting in qdisc.
> > >
> > > Yes I noticed that and said to myself :
> > > This was to let high priority packets have their own limit,
> > > independent on fact that low priority packets filled their queue.
> >
> >
> > Good point, but then logically it could be something like:
> > if (skb_queue_len(list) < qdisc_dev(qdisc)->tx_queue_len / 3)
> >
> > Of course, there is a backward compatibility question, plus
> > an sch_prio consistency question.
>
> Jarek, what is the consistency problem?
Currently pfifo_fast and sch_prio behave similarly wrt. tx_queue_len,
don't they?
Jarek P.
^ permalink raw reply
* Re: ipw2200: firmware DMA loading rework
From: Bartlomiej Zolnierkiewicz @ 2009-08-30 12:37 UTC (permalink / raw)
To: Zhu Yi
Cc: Andrew Morton, Mel Gorman, Johannes Weiner, Pekka Enberg,
Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Mel Gorman, netdev@vger.kernel.org, linux-mm@kvack.org,
James Ketrenos, Chatre, Reinette, linux-wireless@vger.kernel.org,
ipw2100-devel@lists.sourceforge.net
In-Reply-To: <1251430951.3704.181.camel@debian>
On Friday 28 August 2009 05:42:31 Zhu Yi wrote:
> Bartlomiej Zolnierkiewicz reported an atomic order-6 allocation failure
> for ipw2200 firmware loading in kernel 2.6.30. High order allocation is
s/2.6.30/2.6.31-rc6/
The issue has always been there but it was some recent change that
explicitly triggered the allocation failures (after 2.6.31-rc1).
> likely to fail and should always be avoided.
>
> The patch fixes this problem by replacing the original order-6
> pci_alloc_consistent() with an array of order-1 pages from a pci pool.
> This utilized the ipw2200 DMA command blocks (up to 64 slots). The
> maximum firmware size support remains the same (64*8K).
>
> This patch fixes bug http://bugzilla.kernel.org/show_bug.cgi?id=14016
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Mel Gorman <mel@csn.ul.ie>
> Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Thanks for the fix (also kudos to other people helping with the bugreport),
it works fine so far and looks OK to me:
Tested-and-reviewed-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH] tun: reuse struct sock fields
From: Michael S. Tsirkin @ 2009-08-30 17:04 UTC (permalink / raw)
To: David Miller, m.s.tsirkin; +Cc: mst, netdev, herbert
As tun always has an embeedded struct sock,
use sk and sk_receive_queue fields instead of
duplicating them in tun_struct.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
This patch is on top of net-next.
Any comments? Thanks.
drivers/net/tun.c | 30 ++++++++++++------------------
1 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 2533f5c..37e13af 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -103,13 +103,10 @@ struct tun_struct {
uid_t owner;
gid_t group;
- struct sk_buff_head readq;
-
struct net_device *dev;
struct fasync_struct *fasync;
struct tap_filter txflt;
- struct sock *sk;
struct socket socket;
#ifdef TUN_DEBUG
@@ -155,7 +152,7 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
tfile->tun = tun;
tun->tfile = tfile;
dev_hold(tun->dev);
- sock_hold(tun->sk);
+ sock_hold(tun->socket.sk);
atomic_inc(&tfile->count);
out:
@@ -171,7 +168,7 @@ static void __tun_detach(struct tun_struct *tun)
netif_tx_unlock_bh(tun->dev);
/* Drop read queue */
- skb_queue_purge(&tun->readq);
+ skb_queue_purge(&tun->socket.sk->sk_receive_queue);
/* Drop the extra count on the net device */
dev_put(tun->dev);
@@ -340,7 +337,7 @@ static void tun_free_netdev(struct net_device *dev)
{
struct tun_struct *tun = netdev_priv(dev);
- sock_put(tun->sk);
+ sock_put(tun->socket.sk);
}
/* Net device open. */
@@ -374,7 +371,7 @@ static int tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
if (!check_filter(&tun->txflt, skb))
goto drop;
- if (skb_queue_len(&tun->readq) >= dev->tx_queue_len) {
+ if (skb_queue_len(&tun->socket.sk->sk_receive_queue) >= dev->tx_queue_len) {
if (!(tun->flags & TUN_ONE_QUEUE)) {
/* Normal queueing mode. */
/* Packet scheduler handles dropping of further packets. */
@@ -391,7 +388,7 @@ static int tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
}
/* Enqueue packet */
- skb_queue_tail(&tun->readq, skb);
+ skb_queue_tail(&tun->socket.sk->sk_receive_queue, skb);
dev->trans_start = jiffies;
/* Notify and wake up reader process */
@@ -492,13 +489,13 @@ static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
if (!tun)
return POLLERR;
- sk = tun->sk;
+ sk = tun->socket.sk;
DBG(KERN_INFO "%s: tun_chr_poll\n", tun->dev->name);
poll_wait(file, &tun->socket.wait, wait);
- if (!skb_queue_empty(&tun->readq))
+ if (!skb_queue_empty(&sk->sk_receive_queue))
mask |= POLLIN | POLLRDNORM;
if (sock_writeable(sk) ||
@@ -519,7 +516,7 @@ static inline struct sk_buff *tun_alloc_skb(struct tun_struct *tun,
size_t prepad, size_t len,
size_t linear, int noblock)
{
- struct sock *sk = tun->sk;
+ struct sock *sk = tun->socket.sk;
struct sk_buff *skb;
int err;
@@ -787,7 +784,7 @@ static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv,
current->state = TASK_INTERRUPTIBLE;
/* Read frames from the queue */
- if (!(skb=skb_dequeue(&tun->readq))) {
+ if (!(skb=skb_dequeue(&tun->socket.sk->sk_receive_queue))) {
if (file->f_flags & O_NONBLOCK) {
ret = -EAGAIN;
break;
@@ -824,8 +821,6 @@ static void tun_setup(struct net_device *dev)
{
struct tun_struct *tun = netdev_priv(dev);
- skb_queue_head_init(&tun->readq);
-
tun->owner = -1;
tun->group = -1;
@@ -991,7 +986,6 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
sk->sk_write_space = tun_sock_write_space;
sk->sk_sndbuf = INT_MAX;
- tun->sk = sk;
container_of(sk, struct tun_sock, sk)->tun = tun;
tun_net_init(dev);
@@ -1249,7 +1244,7 @@ static long tun_chr_ioctl(struct file *file, unsigned int cmd,
break;
case TUNGETSNDBUF:
- sndbuf = tun->sk->sk_sndbuf;
+ sndbuf = tun->socket.sk->sk_sndbuf;
if (copy_to_user(argp, &sndbuf, sizeof(sndbuf)))
ret = -EFAULT;
break;
@@ -1260,7 +1255,7 @@ static long tun_chr_ioctl(struct file *file, unsigned int cmd,
break;
}
- tun->sk->sk_sndbuf = sndbuf;
+ tun->socket.sk->sk_sndbuf = sndbuf;
break;
default:
@@ -1343,7 +1338,7 @@ static int tun_chr_close(struct inode *inode, struct file *file)
tun = tfile->tun;
if (tun)
- sock_put(tun->sk);
+ sock_put(tun->socket.sk);
put_net(tfile->net);
kfree(tfile);
--
1.6.2.5
^ permalink raw reply related
* Re: r8169 NETDEV WATCHDOG: eth0: transmit timed out [0/8]
From: Francois Romieu @ 2009-08-30 20:26 UTC (permalink / raw)
To: David Dillow; +Cc: roma1390, linux-kernel, netdev
In-Reply-To: <1251553180.13707.16.camel@obelisk.thedillows.org>
David Dillow <dave@thedillows.org> :
> On Sat, 2009-08-29 at 12:16 +0300, roma1390 wrote:
> > Using 3 different r8169 devices on 2 servers (from 2 server so 100% of
> > population) we getting
> >
> > NETDEV WATCHDOG: eth0: transmit timed out
>
> You're running an old version of the kernel, and the driver was patched
> to fix that issue in 2.6.30. It is also in the 2.6.29.x stable series,
> and I think maybe the 2.6.28.x series -- please try those and see if you
> problem is resolved.
The fix in 2.6.28.x targets the netdev watchdog problem at boot time only.
2.6.28.x does not include something similar to
f11a377b3f4e897d11f0e8d1fc688667e2f19708 so 2.6.28.x will almost surely
not fit.
--
Ueimor
^ permalink raw reply
* Re: [PATCH] r8169: Reduce looping in the interrupt handler.
From: Francois Romieu @ 2009-08-30 20:37 UTC (permalink / raw)
To: David Dillow
Cc: Eric W. Biederman, Michael Riepe, Michael Buesch, Rui Santos,
Michael B??ker, linux-kernel, netdev
In-Reply-To: <1251422978.21865.2.camel@obelisk.thedillows.org>
David Dillow <dave@thedillows.org> :
[...]
> It'll be this weekend, but I can see cases where it can lock my chip up
> -- they should be rare, but then I thought your case would be extremely
> rare...
I don't get it.
Can you elaborate the relevant cases or give some sample scenarios for
them ?
--
Ueimor
^ permalink raw reply
* Re: [PATCH] r8169: Reduce looping in the interrupt handler.
From: Eric W. Biederman @ 2009-08-30 20:53 UTC (permalink / raw)
To: Francois Romieu
Cc: David Dillow, Michael Riepe, Michael Buesch, Rui Santos,
Michael B??ker, linux-kernel, netdev
In-Reply-To: <20090830203735.GA24912@electric-eye.fr.zoreil.com>
Francois Romieu <romieu@fr.zoreil.com> writes:
> David Dillow <dave@thedillows.org> :
> [...]
>> It'll be this weekend, but I can see cases where it can lock my chip up
>> -- they should be rare, but then I thought your case would be extremely
>> rare...
>
> I don't get it.
>
> Can you elaborate the relevant cases or give some sample scenarios for
> them ?
I think David is referring to the fact that in the NAPI loop there is
nothing that acks everything.
Eric
^ permalink raw reply
* [PATCH] net: Fix sock freeing before sock_init_data() with __sk_free()
From: Jarek Poplawski @ 2009-08-30 22:23 UTC (permalink / raw)
To: David Miller; +Cc: Eric Dumazet, netdev
After recent changes sk_free() frees socks conditionally and depends
on sk_wmem_alloc beeing set e.g. in sock_init_data(). But in some
cases sk_free() is called earlier, usually after other alloc errors.
This patch fixes it by exporting and using __sk_free() directly.
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
---
include/net/sock.h | 1 +
net/ax25/af_ax25.c | 6 +++---
net/core/sock.c | 6 ++++--
net/irda/af_irda.c | 4 ++--
net/tipc/socket.c | 2 +-
5 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 950409d..e76ef65 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -935,6 +935,7 @@ extern void release_sock(struct sock *sk);
extern struct sock *sk_alloc(struct net *net, int family,
gfp_t priority,
struct proto *prot);
+extern void __sk_free(struct sock *sk);
extern void sk_free(struct sock *sk);
extern void sk_release_kernel(struct sock *sk);
extern struct sock *sk_clone(const struct sock *sk,
diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
index da0f64f..c05738c 100644
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -851,7 +851,7 @@ static int ax25_create(struct net *net, struct socket *sock, int protocol)
ax25 = sk->sk_protinfo = ax25_create_cb();
if (!ax25) {
- sk_free(sk);
+ __sk_free(sk);
return -ENOMEM;
}
@@ -876,7 +876,7 @@ struct sock *ax25_make_new(struct sock *osk, struct ax25_dev *ax25_dev)
return NULL;
if ((ax25 = ax25_create_cb()) == NULL) {
- sk_free(sk);
+ __sk_free(sk);
return NULL;
}
@@ -886,7 +886,7 @@ struct sock *ax25_make_new(struct sock *osk, struct ax25_dev *ax25_dev)
case SOCK_SEQPACKET:
break;
default:
- sk_free(sk);
+ __sk_free(sk);
ax25_cb_put(ax25);
return NULL;
}
diff --git a/net/core/sock.c b/net/core/sock.c
index bbb25be..92793be 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1031,7 +1031,7 @@ struct sock *sk_alloc(struct net *net, int family, gfp_t priority,
}
EXPORT_SYMBOL(sk_alloc);
-static void __sk_free(struct sock *sk)
+void __sk_free(struct sock *sk)
{
struct sk_filter *filter;
@@ -1054,13 +1054,15 @@ static void __sk_free(struct sock *sk)
put_net(sock_net(sk));
sk_prot_free(sk->sk_prot_creator, sk);
}
+EXPORT_SYMBOL(__sk_free);
void sk_free(struct sock *sk)
{
/*
* We substract one from sk_wmem_alloc and can know if
* some packets are still in some tx queue.
- * If not null, sock_wfree() will call __sk_free(sk) later
+ * If not null, sock_wfree() will call __sk_free(sk) later.
+ * (Before sock_init_data() etc. use __sk_free() instead.)
*/
if (atomic_dec_and_test(&sk->sk_wmem_alloc))
__sk_free(sk);
diff --git a/net/irda/af_irda.c b/net/irda/af_irda.c
index 50b43c5..9ed2060 100644
--- a/net/irda/af_irda.c
+++ b/net/irda/af_irda.c
@@ -1118,12 +1118,12 @@ static int irda_create(struct net *net, struct socket *sock, int protocol)
self->max_sdu_size_rx = TTP_SAR_UNBOUND;
break;
default:
- sk_free(sk);
+ __sk_free(sk);
return -ESOCKTNOSUPPORT;
}
break;
default:
- sk_free(sk);
+ __sk_free(sk);
return -ESOCKTNOSUPPORT;
}
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 1848693..4c8435a 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -228,7 +228,7 @@ static int tipc_create(struct net *net, struct socket *sock, int protocol)
tp_ptr = tipc_createport_raw(sk, &dispatch, &wakeupdispatch,
TIPC_LOW_IMPORTANCE);
if (unlikely(!tp_ptr)) {
- sk_free(sk);
+ __sk_free(sk);
return -ENOMEM;
}
^ permalink raw reply related
* Re: Pull request: bluetooth-next-2.6 2009-08-30
From: David Miller @ 2009-08-31 4:47 UTC (permalink / raw)
To: marcel; +Cc: netdev
In-Reply-To: <cover.1251621661.git.marcel@holtmann.org>
From: Marcel Holtmann <marcel@holtmann.org>
Date: Sun, 30 Aug 2009 01:50:14 -0700
> these are the updates for the Bluetooth subsystem for the 2.6.32 merge
> window. On the driver side we have support for Marvell SDIO devices and
> the Bluetooth USB driver got support for auto-suspend. On the core stack
> part we have support for L2CAP enhanced retransmission mode now. The rest
> are random fixes and cleanups.
Looks good, all pulled into net-next-2.6
^ permalink raw reply
* Re: [PATCH 1/5] ucc_geth: Fix NULL pointer dereference in uec_get_ethtool_stats()
From: David Miller @ 2009-08-31 4:52 UTC (permalink / raw)
To: avorontsov; +Cc: leoli, galak, timur, scottwood, linuxppc-dev, netdev
In-Reply-To: <20090827173547.GA1580@oksana.dev.rtsoft.ru>
All 5 patches applied to net-next-2.6
I would have liked to have seen at least one powerpc ACK for
patch #2 but these were posted more than a week ago, the
patch looks pretty reasonable, and we can't wait forever for
stuff like this.
^ permalink raw reply
* Re: [PATCH 0/3] [v3] Revert Backoff on ICMP destination unreachable
From: David Miller @ 2009-08-31 4:56 UTC (permalink / raw)
To: damian; +Cc: netdev, ilpo.jarvinen
In-Reply-To: <4A950B76.1070002@tvk.rwth-aachen.de>
From: Damian Lukowski <damian@tvk.rwth-aachen.de>
Date: Wed, 26 Aug 2009 12:16:22 +0200
> This series of patches implements the TCP improvement of the Internet Draft
> "Make TCP more Robust to Long Connectivity Disruptions"
> (http://tools.ietf.org/html/draft-zimmermann-tcp-lcd).
>
> Exponential backoff is TCP's standard behaviour during long connectivity
> disruptions, which is a countermeasure against network congestion.
> If congestion can be excluded as the reason for RTO retransmission loss,
> backoff is not desirable, as it yields longer TCP recovery times, when
> the communication path is repaired shortly after an unsuccessful
> retransmission probe.
>
> 1) This patch renames the skb in tcp_v4_err() in preparation for patch 2.
> 2) Contains the main reversion logic.
> Reintroduces tcp_bound_rto() and __tcp_set_rto()
> 3) This patch modifies the interpretation of the tcp_retries{1,2} sysctls.
> It became necessary because with patch2 the assumption that the number
> of retransmits corresponds to an specific timeout value is not accurate
> anymore. With this patch tcp_retries{1,2} specifies a timeout value,
> equivalent to the time a connection with an rto value of MIN_RTO (200ms)
> would need to retransmit N segments. IOW: The meaning (in sense of time)
> is mostly preserved, but the actual connection timeout does not depend
> on the calculated rto of the connection, anymore.
>
> Signed-off-by: Damian Lukowski <damian@tvk.rwth-aachen.de>
Ilpo can you please review this new version of Damian's changes?
Thanks.
^ permalink raw reply
* Re: [PATCH 1/3] drop_monitor: fix trace_napi_poll_hit()
From: David Miller @ 2009-08-31 4:57 UTC (permalink / raw)
To: xiaoguangrong
Cc: mingo, rostedt, fweisbec, nhorman, yjwei, linux-kernel, netdev
In-Reply-To: <4A966288.8020402@cn.fujitsu.com>
Xiao, can you please resend this patch series cleanly?
I see two submissions of patch #3 and I have no copies
at all of patch #2.
Thanks.
^ permalink raw reply
* Re: [PATCH] WAN: bit and/or confusion
From: David Miller @ 2009-08-31 5:02 UTC (permalink / raw)
To: roel.kluin; +Cc: khc, akpm, romieu, netdev
In-Reply-To: <4A8D57F8.1050106@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Thu, 20 Aug 2009 16:04:40 +0200
> Fix the tests that check whether Frame* bits are not set
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH]gianfar: gfar_remove needs to call unregister_netdev()
From: David Miller @ 2009-08-31 5:04 UTC (permalink / raw)
To: uchiyama.toru; +Cc: netdev
In-Reply-To: <4A8D559B.3030108@jp.fujitsu.com>
From: Toru UCHIYAMA <uchiyama.toru@jp.fujitsu.com>
Date: Thu, 20 Aug 2009 22:54:35 +0900
> This patch solves the problem that the Oops(BUG_ON) occurs by rmmod.
...
> Signed-off-by: uchiyama.toru@jp.fujitsu.com
Applied, thank you.
In the future, please list your name as well as your email
address in the Signed-off-by: specification.
Thank you.
^ permalink raw reply
* Re: [PATCH] Re: iproute2 / tbf with large burst seems broken again
From: David Miller @ 2009-08-31 5:05 UTC (permalink / raw)
To: jarkao2; +Cc: denys, netdev
In-Reply-To: <20090826215956.GA5148@ami.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Wed, 26 Aug 2009 23:59:56 +0200
> Denys Fedoryschenko wrote, On 08/25/2009 02:18 PM:
> ...
>> Just maybe good idea in next kernels to document this or handle overflow, that
>> it will give warning in kernel. Otherwise user will have non-functional qdisc
>> that will not pass traffic.
>
> OK, if this patch works for you send your Tested-by, please.
Denys, please give Jarek's patch some testing and let us know
if it triggers properly for you.
> Thanks,
> Jarek P.
> ---------------->
> pkt_sched: Warn on tokens overflow in tbf_dequeue
>
> After recent change of scheduling resolution some "extreme" configs
> can cause token overflows with stalls. This patch warns when tokens
> were negative before accounting for a packet length.
>
> Reported-by: Denys Fedoryschenko <denys@visp.net.lb>
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
> ---
>
> net/sched/sch_tbf.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/net/sched/sch_tbf.c b/net/sched/sch_tbf.c
> index e22dfe8..ef191c4 100644
> --- a/net/sched/sch_tbf.c
> +++ b/net/sched/sch_tbf.c
> @@ -191,6 +191,12 @@ static struct sk_buff *tbf_dequeue(struct Qdisc* sch)
> return skb;
> }
>
> + if (unlikely((long)(toks + L2T(q, len)) < 0 ||
> + (long)(ptoks + L2T_P(q, len) < 0)))
> + if (net_ratelimit())
> + pr_warning("tbf: tokens overflow;"
> + " fix limits.\n");
> +
> qdisc_watchdog_schedule(&q->watchdog,
> now + max_t(long, -toks, -ptoks));
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH][net-next] LRO: improve aggregation in case of zero TSecr packets
From: David Miller @ 2009-08-31 5:11 UTC (permalink / raw)
To: opurdila; +Cc: themann, raisch, eric.dumazet, netdev
In-Reply-To: <200908270208.31581.opurdila@ixiacom.com>
From: Octavian Purdila <opurdila@ixiacom.com>
Date: Thu, 27 Aug 2009 02:08:31 +0300
> This fixes a temporary performance issue we noticed in back to back
> TSO - LRO tests when such tests are run within five minutes after
> boot.
>
> The TSval field of TCP packets is filled in based on the current
> jiffie, which is initialized at -300*HZ. That means that in 5 minutes
> after reboot it will wrap to zero.
RFC1323 says we absolutely must ignore zero TSecr values.
It is a bug that the stack emits a zero value when it means to give a
real TSecr value that will be used.
Probably we can do something like emit '1' when we would emit '0'
based upon jiffies.
And this would be an improvement from now in that having a off-by-one
TSecr in this situation is better than emitting one which we can
guarentee will be ignored.
^ permalink raw reply
* Re: [PATCH net-next-2.6] can: use correct NET_RX_ return values
From: David Miller @ 2009-08-31 5:13 UTC (permalink / raw)
To: oliver; +Cc: netdev
In-Reply-To: <4A995B15.4020303@hartkopp.net>
From: Oliver Hartkopp <oliver@hartkopp.net>
Date: Sat, 29 Aug 2009 18:45:09 +0200
> Dropped skb's should be documented by an appropriate return value.
> Use the correct NET_RX_DROP and NET_RX_SUCCESS values for that reason.
>
> Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] netdevice: Use existing macros
From: David Miller @ 2009-08-31 5:15 UTC (permalink / raw)
To: krkumar2; +Cc: netdev
In-Reply-To: <20090830062121.6296.60149.sendpatchset@localhost.localdomain>
From: Krishna Kumar <krkumar2@in.ibm.com>
Date: Sun, 30 Aug 2009 11:51:21 +0530
> From: Krishna Kumar <krkumar2@in.ibm.com>
>
> netdevice: Consolidate to use existing macros where available.
>
> Patch compiled and 32 simultaneous netperf testing ran fine.
>
> Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: convert one non-symbolic return value in dev_queue_xmit
From: David Miller @ 2009-08-31 5:18 UTC (permalink / raw)
To: krkumar2; +Cc: netdev
In-Reply-To: <20090830062136.6299.31696.sendpatchset@localhost.localdomain>
From: Krishna Kumar <krkumar2@in.ibm.com>
Date: Sun, 30 Aug 2009 11:51:36 +0530
> From: Krishna Kumar <krkumar2@in.ibm.com>
>
> net: convert remaining non-symbolic return values in dev_queue_xmit
>
> Patch compiled and 32 simultaneous netperf testing ran fine.
>
> Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
Applied, but please do me a favor.
Do not provide two commit message header lines like this.
They aren't even equal.
Whatever you give me in the Subject line after "[....] " is what
ends up being the commit message header line when I apply your
patch.
Adding another commit header line in your email message body just
makes the commit look confusing and ugly.
So just give me one in the subject line and elide the one in the
message body.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH] sched: Fix resource limiting in pfifo_fast
From: David Miller @ 2009-08-31 5:19 UTC (permalink / raw)
To: krkumar2; +Cc: netdev
In-Reply-To: <20090830062344.6380.16713.sendpatchset@localhost.localdomain>
From: Krishna Kumar <krkumar2@in.ibm.com>
Date: Sun, 30 Aug 2009 11:53:44 +0530
> From: Krishna Kumar <krkumar2@in.ibm.com>
>
> pfifo_fast_enqueue has this check:
> if (skb_queue_len(list) < qdisc_dev(qdisc)->tx_queue_len) {
>
> which allows each band to enqueue upto tx_queue_len skbs for a
> total of 3*tx_queue_len skbs. I am not sure if this was the
> intention of limiting in qdisc.
>
> Patch compiled and 32 simultaneous netperf testing ran fine. Also:
> # tc -s qdisc show dev eth2
> qdisc pfifo_fast 0: root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
> Sent 16835026752 bytes 373116 pkt (dropped 0, overlimits 0 requeues 25)
> rate 0bit 0pps backlog 0b 0p requeues 25
>
> (I am taking next week off, so sorry for any delay in responding)
>
> Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
This is probably just a thinko, nice catch.
I think I'll apply this to net-next-2.6, thanks!
^ permalink raw reply
* RE: [PATCH 0/9] drivers/net/s2io.c: Cleanups
From: Sreenivasa Honnur @ 2009-08-31 5:21 UTC (permalink / raw)
To: Joe Perches, David Miller
Cc: netdev, Anil Murthy, Sivakumar Subramani, Rastapur Santosh,
Ramkrishna Vepa, akpm, linux-next
In-Reply-To: <1251326878.13026.52.camel@Joe-Laptop.home>
Joe,
Patches look fine, I reviewed and tested these patches on latest
davem-net-next-2.6 sources.
Acked-by: Sreenivasa Honnur <sreenivasa.honnur@neterion.com>
Regs
srini
-----Original Message-----
From: Joe Perches [mailto:joe@perches.com]
Sent: Thursday, August 27, 2009 4:18 AM
To: David Miller
Cc: netdev@vger.kernel.org; Anil Murthy; Sreenivasa Honnur; Sivakumar
Subramani; Rastapur Santosh; Ramkrishna Vepa; akpm@linux-foundation.org;
linux-next@vger.kernel.org
Subject: Re: [PATCH 0/9] drivers/net/s2io.c: Cleanups
On Wed, 2009-08-26 at 15:33 -0700, David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Mon, 24 Aug 2009 20:29:39 -0700
> > Just a few cleanups, compiled, untested. No hardware.
> > s2io.c: Use const for strings
> > s2io.c: Shorten code line length by using intermediate pointers
> > s2io.c: Use calculated size in kmallocs
> > s2io.c: use kzalloc
> > s2io.c: Make more conforming to normal kernel style
> > s2io.c: convert printks to pr_<level>
> > s2io.c: fix spelling explaination
> > s2io.c: Standardize statistics accessors
> > s2io.c: Convert skipped nic->config.tx_cfg[i]. to tx_cfg->
>
> Since this is a pretty serious set of cleanups, I'd like to let the
> S2IO driver folks have some time to look at this and at least have a
> chance to ACK/NACK them.
No worries. That's fine. It's only cleanups.
I haven't heard from them though and they haven't submitted or signed a
patch for s2io in over a year.
Hey! Neterion people! Is anybody home?
^ permalink raw reply
* Re: [PATCH] Re: iproute2 / tbf with large burst seems broken again
From: Jarek Poplawski @ 2009-08-31 5:30 UTC (permalink / raw)
To: David Miller; +Cc: denys, netdev
In-Reply-To: <20090830.220559.77181973.davem@davemloft.net>
On Sun, Aug 30, 2009 at 10:05:59PM -0700, David Miller wrote:
> From: Jarek Poplawski <jarkao2@gmail.com>
> Date: Wed, 26 Aug 2009 23:59:56 +0200
>
> > Denys Fedoryschenko wrote, On 08/25/2009 02:18 PM:
> > ...
> >> Just maybe good idea in next kernels to document this or handle overflow, that
> >> it will give warning in kernel. Otherwise user will have non-functional qdisc
> >> that will not pass traffic.
> >
> > OK, if this patch works for you send your Tested-by, please.
>
> Denys, please give Jarek's patch some testing and let us know
> if it triggers properly for you.
Actually, I think now, after 2.6.31, this patch might be a bit too
late. If people hit this problem they probably should've fixed it
until -next already, so let's forget about this patch until there are
more such reports.
Btw, I guess, Denys could submit some warnings into iproute's code
and/or documentation, as he proposed earlier.
Thanks,
Jarek P.
> > ---------------->
> > pkt_sched: Warn on tokens overflow in tbf_dequeue
> >
> > After recent change of scheduling resolution some "extreme" configs
> > can cause token overflows with stalls. This patch warns when tokens
> > were negative before accounting for a packet length.
> >
> > Reported-by: Denys Fedoryschenko <denys@visp.net.lb>
> > Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
> > ---
> >
> > net/sched/sch_tbf.c | 6 ++++++
> > 1 files changed, 6 insertions(+), 0 deletions(-)
> >
> > diff --git a/net/sched/sch_tbf.c b/net/sched/sch_tbf.c
> > index e22dfe8..ef191c4 100644
> > --- a/net/sched/sch_tbf.c
> > +++ b/net/sched/sch_tbf.c
> > @@ -191,6 +191,12 @@ static struct sk_buff *tbf_dequeue(struct Qdisc* sch)
> > return skb;
> > }
> >
> > + if (unlikely((long)(toks + L2T(q, len)) < 0 ||
> > + (long)(ptoks + L2T_P(q, len) < 0)))
> > + if (net_ratelimit())
> > + pr_warning("tbf: tokens overflow;"
> > + " fix limits.\n");
> > +
> > qdisc_watchdog_schedule(&q->watchdog,
> > now + max_t(long, -toks, -ptoks));
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Re: iproute2 / tbf with large burst seems broken again
From: David Miller @ 2009-08-31 5:32 UTC (permalink / raw)
To: jarkao2; +Cc: denys, netdev
In-Reply-To: <20090831053026.GA5005@ff.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Mon, 31 Aug 2009 05:30:27 +0000
> Actually, I think now, after 2.6.31, this patch might be a bit too
> late. If people hit this problem they probably should've fixed it
> until -next already, so let's forget about this patch until there are
> more such reports.
Ok.
> Btw, I guess, Denys could submit some warnings into iproute's code
> and/or documentation, as he proposed earlier.
Yeah sounds like a good idea.
^ permalink raw reply
* Re: [PATCH 0/9] drivers/net/s2io.c: Cleanups
From: David Miller @ 2009-08-31 5:35 UTC (permalink / raw)
To: Sreenivasa.Honnur
Cc: joe, netdev, Anil.Murthy, Sivakumar.Subramani, santosh.rastapur,
Ramkrishna.Vepa, akpm, linux-next
In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7705A1DF76@nekter>
From: "Sreenivasa Honnur" <Sreenivasa.Honnur@neterion.com>
Date: Mon, 31 Aug 2009 01:21:36 -0400
> Joe,
> Patches look fine, I reviewed and tested these patches on latest
> davem-net-next-2.6 sources.
>
> Acked-by: Sreenivasa Honnur <sreenivasa.honnur@neterion.com>
Great, all patches applied to net-next-2.6, thanks everyone.
^ permalink raw reply
* [PATCH resend] drop_monitor: fix trace_napi_poll_hit()
From: Xiao Guangrong @ 2009-08-31 6:10 UTC (permalink / raw)
To: David Miller; +Cc: Neil Horman, Wei Yongjun, Netdev, LKML
The net_dev of backlog napi is NULL, like below:
__get_cpu_var(softnet_data).backlog.dev == NULL
So, we should check it in napi tracepoint's probe function
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
---
net/core/drop_monitor.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/core/drop_monitor.c b/net/core/drop_monitor.c
index 9d66fa9..d311202 100644
--- a/net/core/drop_monitor.c
+++ b/net/core/drop_monitor.c
@@ -182,7 +182,8 @@ static void trace_napi_poll_hit(struct napi_struct *napi)
/*
* Ratelimit our check time to dm_hw_check_delta jiffies
*/
- if (!time_after(jiffies, napi->dev->last_rx + dm_hw_check_delta))
+ if (!napi->dev ||
+ !time_after(jiffies, napi->dev->last_rx + dm_hw_check_delta))
return;
rcu_read_lock();
--
1.6.1.2
^ permalink raw reply related
* [PATCH resend] tracing/events: convert NAPI's tracepoint via TRACE_EVENT
From: Xiao Guangrong @ 2009-08-31 6:16 UTC (permalink / raw)
To: Ingo Molnar
Cc: David Miller, Neil Horman, Steven Rostedt, Frederic Weisbecker,
Wei Yongjun, Netdev, LKML
- Convert NAPI's tracepoint via TRACE_EVENT macro, the output information
like below:
sshd-2503 [000] 71.920846: napi_poll: ifname=eth0 state=0 weigth=16 poll=pcnet32_poll
sshd-2503 [000] 72.020291: napi_poll: ifname=eth0 state=0 weigth=16 poll=pcnet32_poll
sshd-2503 [000] 72.020418: napi_poll: ifname=eth0 state=NAPI_STATE_SCHED weigth=16 poll=pcnet32_poll
- Remove the "DECLARE_TRACE" definiens in include/trace/define_trace.h,
because TRACE_EVENT not use it
Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
---
include/trace/define_trace.h | 4 ---
include/trace/events/napi.h | 43 +++++++++++++++++++++++++++++++++++++----
2 files changed, 38 insertions(+), 9 deletions(-)
diff --git a/include/trace/define_trace.h b/include/trace/define_trace.h
index 2a4b3bf..6158741 100644
--- a/include/trace/define_trace.h
+++ b/include/trace/define_trace.h
@@ -31,10 +31,6 @@
assign, print, reg, unreg) \
DEFINE_TRACE_FN(name, reg, unreg)
-#undef DECLARE_TRACE
-#define DECLARE_TRACE(name, proto, args) \
- DEFINE_TRACE(name)
-
#undef TRACE_INCLUDE
#undef __TRACE_INCLUDE
diff --git a/include/trace/events/napi.h b/include/trace/events/napi.h
index a8989c4..5c7a192 100644
--- a/include/trace/events/napi.h
+++ b/include/trace/events/napi.h
@@ -1,11 +1,44 @@
-#ifndef _TRACE_NAPI_H_
-#define _TRACE_NAPI_H_
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM napi
+
+#if !defined(_TRACE_NAPI_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_NAPI_H
#include <linux/netdevice.h>
#include <linux/tracepoint.h>
-DECLARE_TRACE(napi_poll,
+#define show_napi_state(state) state ? __print_flags(state, "|", \
+ { (1UL << NAPI_STATE_SCHED), "NAPI_STATE_SCHED" }, \
+ { (1UL << NAPI_STATE_DISABLE), "NAPI_STATE_DISABLE" }, \
+ { (1UL << NAPI_STATE_NPSVC), "NAPI_STATE_NPSVC" }) : "0"
+
+TRACE_EVENT(napi_poll,
+
TP_PROTO(struct napi_struct *napi),
- TP_ARGS(napi));
-#endif
+ TP_ARGS(napi),
+
+ TP_STRUCT__entry(
+ __field( unsigned long, state )
+ __field( int, weight )
+ __field( void *, poll )
+ __string( ifname, (napi->dev ?
+ napi->dev->name : "backlog") )
+ ),
+
+ TP_fast_assign(
+ __entry->state = napi->state;
+ __entry->weight = napi->weight;
+ __entry->poll = napi->poll;
+ __assign_str(ifname, napi->dev ? napi->dev->name : "backlog")
+ ),
+
+ TP_printk("ifname=%s state=%s weight=%d poll=%pf",
+ __get_str(ifname), show_napi_state(__entry->state),
+ __entry->weight, __entry->poll)
+);
+
+#endif /* _TRACE_NAPI_H */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
--
1.6.1.2
^ 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