* Re: [RFC][PATCH] add tracepoint to __sk_mem_schedule
From: Neil Horman @ 2011-06-15 11:07 UTC (permalink / raw)
To: Satoru Moriya
Cc: netdev@vger.kernel.org, davem@davemloft.net,
dle-develop@lists.sourceforge.net, Seiji Aguchi
In-Reply-To: <65795E11DBF1E645A09CEC7EAEE94B9C3FBC0707@USINDEVS02.corp.hds.com>
On Tue, Jun 14, 2011 at 03:24:14PM -0400, Satoru Moriya wrote:
> Hi,
>
> kernel drops packets when the amount of memory which is used for socket buffer
> exceeds limitations such as /proc/sys/net/ipv4/udp_mem. But currently we can't
> catch that event and know why packets are dropped. And also it is difficult to
> configure sysctl knob appropriately because we don't know when/why packets
> dropped.
>
There are several ways to do this already. Every drop that occurs in the stack
should have a corresponding statistical counter exposed for it, and we also have
a tracepoint in kfree_skb that the dropwatch system monitors to inform us of
dropped packets in a certralized fashion. Not saying this tracepoint isn't
worthwhile, only that it covers already covered ground.
> This patch adds tracepoint to __sk_mem_schedule(), which is called each time
> the socket memory usage exceeds limitations and kernel drops a packet.
> It allows us to hook in and examine when and why it happens.
>
> Note that this patch only collects information which is needed for udp
> because it's a RFC patch to show its concept and acutually we need it(*).
> If you guys need to get other parameters, please let me know. I'll add it.
>
> (*) Reason why we need this tracepoint for UDP
> Transaction data is sent by UDP multicast in finance systems because of its
> low overhead characteristics. UDP itself does not guarantee reliability,
> ordering and data integrity, but the system is designed not to drop any packets
> even when it is high load situation. And in that system if kernel drops packets,
> we need to find a root cause to avoid it next time.
>
Again, this is why dropwatch exists. UDP gets into this path from:
__udp_queue_rcv_skb
ip_queue_rcv_skb
sock_queue_rcv_skb
sk_rmem_schedule
__sk_mem_schedule
If ip_queue_rcv_skb fails we increment the UDP_MIB_RCVBUFERRORS counter as well
as the UDP_MIB_INERRORS counter, and on the kfree_skb call after those
increments, dropwatch will report the frame loss and the fact that it occured in
__udp_queue_rcv_skb
I still think its an interesting tracepoint, just because it might be nice to
know which sockets are expanding their snd/rcv buffer space, but why not modify
the tracepoint so that it accepts the return code of __sk_mem_schedule and call
it from both sk_rmem_schedule and sk_wmem_schedule. That way you can use the
tracepoint to record both successfull expansion and failed expansions.
Neil
> Any comments are welcome.
>
> Signed-off-by: Satoru Moriya <satoru.moriya@hds.com>
> ---
> include/trace/events/sock.h | 46 +++++++++++++++++++++++++++++++++++++++++++
> net/core/net-traces.c | 1 +
> net/core/sock.c | 4 +++
> 3 files changed, 51 insertions(+), 0 deletions(-)
> create mode 100644 include/trace/events/sock.h
>
> diff --git a/include/trace/events/sock.h b/include/trace/events/sock.h
> new file mode 100644
> index 0000000..409735a
> --- /dev/null
> +++ b/include/trace/events/sock.h
> @@ -0,0 +1,46 @@
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM sock
> +
> +#if !defined(_TRACE_SOCK_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_SOCK_H
> +
> +#include <net/sock.h>
> +#include <linux/tracepoint.h>
> +
> +TRACE_EVENT(sock_exceed_buf_limit,
> +
> + TP_PROTO(struct sock *sk, struct proto *prot, long allocated),
> +
> + TP_ARGS(sk, prot, allocated),
> +
> + TP_STRUCT__entry(
> + __array(char, name, 32)
> + __field(long *, sysctl_mem)
> + __field(long, allocated)
> + __field(int, sysctl_rmem)
> + __field(int, rmem_alloc)
> + ),
> +
> + TP_fast_assign(
> + strncpy(__entry->name, prot->name, 32);
> + __entry->sysctl_mem = prot->sysctl_mem;
> + __entry->allocated = allocated;
> + __entry->sysctl_rmem = atomic_read(&sk->sk_rmem_alloc);
> + __entry->rmem_alloc = prot->sysctl_rmem[0];
> + ),
> +
> + TP_printk("proto:%s sysctl_mem=%ld,%ld,%ld allocated=%ld "
> + "sysctl_rmem=%d rmem_alloc=%d",
> + __entry->name,
> + __entry->sysctl_mem[0],
> + __entry->sysctl_mem[1],
> + __entry->sysctl_mem[2],
> + __entry->allocated,
> + __entry->sysctl_rmem,
> + __entry->rmem_alloc)
> +);
> +
> +#endif /* _TRACE_SOCK_H */
> +
> +/* This part must be outside protection */
> +#include <trace/define_trace.h>
> diff --git a/net/core/net-traces.c b/net/core/net-traces.c
> index 7f1bb2a..b9756f5 100644
> --- a/net/core/net-traces.c
> +++ b/net/core/net-traces.c
> @@ -28,6 +28,7 @@
> #include <trace/events/skb.h>
> #include <trace/events/net.h>
> #include <trace/events/napi.h>
> +#include <trace/events/sock.h>
>
> EXPORT_TRACEPOINT_SYMBOL_GPL(kfree_skb);
>
> diff --git a/net/core/sock.c b/net/core/sock.c
> index 6e81978..8389032 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -128,6 +128,8 @@
>
> #include <linux/filter.h>
>
> +#include <trace/events/sock.h>
> +
> #ifdef CONFIG_INET
> #include <net/tcp.h>
> #endif
> @@ -1736,6 +1738,8 @@ suppress_allocation:
> return 1;
> }
>
> + trace_sock_exceed_buf_limit(sk, prot, allocated);
> +
> /* Alas. Undo changes. */
> sk->sk_forward_alloc -= amt * SK_MEM_QUANTUM;
> atomic_long_sub(amt, prot->memory_allocated);
> --
> 1.7.1
> --
> 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] linux-firmware: Add a new FW 7.0.20.0 (second try)
From: Vladislav Zolotarov @ 2011-06-15 11:57 UTC (permalink / raw)
To: David Woodhouse, Dave Miller; +Cc: Eilon Greenstein, netdev@vger.kernel.org
In-Reply-To: <alpine.LFD.2.02.1106151138390.8326@localhost6.localdomain6>
>
> > I've sent it to u once again a minute ago.
> > If for any reason u don't get it, the patch is avaliable at
> > http://linux.broadcom.com/eilong/FW-7.0.20.0/
>
> Still didn't seem to get it; fetched patch from HTTP server and
> applied.
I pulled the linux-firmware git and saw the FW files.
Thanks a lot, David.
Dave, what do u want me to do now: do u want me to resend the series?
Thanks,
vlad
>
> --
> dwmw2
>
> --
> 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
* (unknown),
From: Людмила @ 2011-06-14 14:12 UTC (permalink / raw)
ищу партнера для секса
http://4p5.com/244c
^ permalink raw reply
* kernel 2.6.32-27 crash in tcp
From: Vishal Study @ 2011-06-15 12:57 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev
In-Reply-To: <BANLkTi=pgbKHtSX9rhnunvoYYQjMMtdpPg@mail.gmail.com>
Hello,
I'm using kernel 2.6.32-27 on a mips platform and get following kernel crash.
I'm running open-source IET iSCSI Stack and get this error during
heavy load test. Any ideas on what could be happening or if this is
known issue in 2.6.32 kernel?
Thanks,
Vishal.
------------[ cut here ]------------
WARNING: at net/ipv4/tcp.c:1457 tcp_recvmsg+0x7c0/0x990()
recvmsg bug 2: copied 8D07C2AD seq 1EAA6653 rcvnxt 8D083A71 fl 4000
Modules linked in: iscsi_trgt test_ethernet ipv6
Call Trace:
[<ffffffff801127d0>] dump_stack+0x8/0x34
[<ffffffff8024a8e8>] warn_slowpath_common+0x70/0xb0
[<ffffffff8024a97c>] warn_slowpath_fmt+0x34/0x40
[<ffffffff805c0130>] tcp_recvmsg+0x7c0/0x990
[<ffffffff8057bd8c>] sock_common_recvmsg+0x34/0x58
[<ffffffff8057a050>] sock_recvmsg+0x100/0x140
[<ffffffffc0081800>] do_recv+0x120/0x238 [iscsi_trgt]
[<ffffffffc0081ef8>] istd+0x5e0/0x1408 [iscsi_trgt]
[<ffffffff80264820>] kthread+0x88/0x90
[<ffffffff80221ea8>] kernel_thread_helper+0x10/0x18
^ permalink raw reply
* [patch -next] rtnetlink: unlock on error path in netlink_dump()
From: Dan Carpenter @ 2011-06-15 13:11 UTC (permalink / raw)
To: Greg Rose
Cc: Eric Dumazet, Patrick McHardy, Chris Wright, David S. Miller,
Jeff Kirsher, open list:NETWORKING [GENERAL], kernel-janitors
In c7ac8679bec939 "rtnetlink: Compute and store minimum ifinfo dump
size", we moved the allocation under the lock so we need to unlock
on error path.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 0b92f7549..ca5276c 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1676,7 +1676,7 @@ static int netlink_dump(struct sock *sk)
skb = sock_rmalloc(sk, alloc_size, 0, GFP_KERNEL);
if (!skb)
- goto errout;
+ goto errout_skb;
len = cb->dump(skb, cb);
@@ -1716,7 +1716,6 @@ static int netlink_dump(struct sock *sk)
errout_skb:
mutex_unlock(nlk->cb_mutex);
kfree_skb(skb);
-errout:
return err;
}
^ permalink raw reply related
* Re: tc match MAC destination
From: Thomas Graf @ 2011-06-15 13:23 UTC (permalink / raw)
To: Andrei Popa; +Cc: pdoru.kernel, netdev
In-Reply-To: <1308125523.30324.64.camel@ierdnac-hp>
On Wed, Jun 15, 2011 at 11:12:01AM +0300, Andrei Popa wrote:
> I want to shape PVSTP+ traffic (traffic that has MAC destination
> 01:00:0c:cc:cc:cd) and it doesn't work.
> I've tried
> filter parent 1: protocol 802_3 pref 2 u32 fh 802::11 order 17 key ht
> 802 bkt 0 flowid 1:3
> match 01000ccc/ffffffff at 0
> but it doesn't work.
u32 offset 0 corresponds to the network layer and thus will
match the first byte of the ip layer or whatever protocol
is found on that layer.
You can use the cmp ematch to match on the mac layer:
Use something like this:
filter add basic match 'cmp(0x01000ccc at 0 layer link mask 0xffffffff)'
... cmp(>>help<<)...
Usage: cmp(ALIGN at OFFSET [ ATTRS ] { eq | lt | gt } VALUE)
where: ALIGN := { u8 | u16 | u32 }
ATTRS := [ layer LAYER ] [ mask MASK ] [ trans ]
LAYER := { link | network | transport | 0..2 }
Example: cmp(u16 at 3 layer 2 mask 0xff00 gt 20
^ permalink raw reply
* Re: tc match MAC destination
From: Stephen Hemminger @ 2011-06-15 13:29 UTC (permalink / raw)
To: ierdnah; +Cc: linux-kernel, pdoru.kernel, netdev
In-Reply-To: <1308125523.30324.64.camel@ierdnac-hp>
On Wed, 15 Jun 2011 11:12:01 +0300
Andrei Popa <ierdnah@gmail.com> wrote:
> Hello,
>
> I want to shape PVSTP+ traffic (traffic that has MAC destination
> 01:00:0c:cc:cc:cd) and it doesn't work.
> I've tried
> filter parent 1: protocol 802_3 pref 2 u32 fh 802::11 order 17 key ht
> 802 bkt 0 flowid 1:3
> match 01000ccc/ffffffff at 0
> but it doesn't work.
>
> With
> filter parent 1: protocol arp pref 1 u32
> filter parent 1: protocol arp pref 1 u32 fh 801: ht divisor 1
> filter parent 1: protocol arp pref 1 u32 fh 801::7 order 7 key ht 801
> bkt 0 flowid 1:3
> match 00000000/00000000 at 0
> filter parent 1: protocol 802_3 pref 2 u32
> filter parent 1: protocol 802_3 pref 2 u32 fh 802: ht divisor 1
> filter parent 1: protocol 802_3 pref 2 u32 fh 802::3 order 3 key ht 802
> bkt 0 flowid 1:3
> match 00000000/00000000 at 0
> action order 1: mirred (Egress Mirror to device ifb1) pipe
> index 1923 ref 1 bind 1
>
> I see arp trafic with tcpdump on ifb1, but no STP traffic or any kind of
> traffic except arp, because I've matched all MAC addreses.
> Can somebody verify that this match works ?
>
> I use kernel 2.6.39.1.
>
> Thank you,
If you use current iproute tools it is possible to use:
tc filter ... match ether dst 01:00:0c:cc:cc:cd
which generates the necessary offset.
^ permalink raw reply
* HELLO DEAR
From: aliciahamed20 @ 2011-06-15 13:38 UTC (permalink / raw)
To: aliciahamed20
Hello dear,
My name is Alicia Hamed I am a girl, I saw your profile here and my spirite ask me to contact you about this important issue so please, I would like you to send me mail here{aliciahamed20@live.com} so that i will tell you about the important issue and also give you my sweet picture. I am waiting for your urgent and immediate reply
thank you
Miss Alicia
^ permalink raw reply
* [RFC 3/5 v3] net: restore net_create and make it globally visible
From: Vasiliy Kulikov @ 2011-06-15 13:58 UTC (permalink / raw)
To: linux-kernel
Cc: kernel-hardening, Andrew Morton, Greg Kroah-Hartman,
David S. Miller, Arnd Bergmann, Eric W. Biederman, Daniel Lezcano,
Paul E. McKenney, Stephen Rothwell, netdev
This reverts commit 911cb193f3eb0370f20fbba712211e55ffede4de and
makes net_create() globally visible. net_create() will be needed
for fake_net in fs/proc/proc_net.c.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
---
include/net/net_namespace.h | 2 ++
net/core/net_namespace.c | 12 ++++++++----
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index 2bf9ed9..5d5328c 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -116,6 +116,8 @@ static inline struct net *copy_net_ns(unsigned long flags, struct net *net_ns)
}
#endif /* CONFIG_NET */
+extern struct net *net_create(void);
+
extern struct list_head net_namespace_list;
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 6c6b86d..c90f0db 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -210,14 +210,11 @@ static void net_free(struct net *net)
kmem_cache_free(net_cachep, net);
}
-struct net *copy_net_ns(unsigned long flags, struct net *old_net)
+struct net *net_create(void)
{
struct net *net;
int rv;
- if (!(flags & CLONE_NEWNET))
- return get_net(old_net);
-
net = net_alloc();
if (!net)
return ERR_PTR(-ENOMEM);
@@ -236,6 +233,13 @@ struct net *copy_net_ns(unsigned long flags, struct net *old_net)
return net;
}
+struct net *copy_net_ns(unsigned long flags, struct net *old_net)
+{
+ if (!(flags & CLONE_NEWNET))
+ return get_net(old_net);
+ return net_create();
+}
+
static DEFINE_SPINLOCK(cleanup_list_lock);
static LIST_HEAD(cleanup_list); /* Must hold cleanup_list_lock to touch */
--
1.7.0.4
^ permalink raw reply related
* Re: [Security] inet_diag insufficient validation?
From: Dan Rosenberg @ 2011-06-15 14:35 UTC (permalink / raw)
To: Eugene Teo; +Cc: davem, kuznet, netdev, security, Arnaldo Carvalho de Melo
In-Reply-To: <BANLkTin9fqYSxq4ne5hV_ri-zKeMZ9mE_g@mail.gmail.com>
On Fri, 2011-06-03 at 14:55 +0800, Eugene Teo wrote:
> Cc'ed acme.
>
> On Wed, Jun 1, 2011 at 11:40 PM, Dan Rosenberg <drosenberg@vsecurity.com> wrote:
> > It seems to me that the auditing performed by inet_diag_bc_audit() is
> > insufficient to prevent pathological INET_DIAG bytecode from doing bad
> > things.
> >
> > Firstly, it's possible to cause an infinite loop in inet_diag_bc_audit()
> > with a INET_DIAG_BC_JMP opcode with a "yes" value of 0. The valid_cc()
> > function, also called from here, seems suspicious as well.
> >
Any chance of getting this fixed? I have a reproducer available if
necessary.
-Dan
^ permalink raw reply
* Re: [PATCH] linux-firmware: Add a new FW 7.0.20.0 (second try)
From: David Miller @ 2011-06-15 14:47 UTC (permalink / raw)
To: vladz; +Cc: dwmw2, eilong, netdev
In-Reply-To: <8628FE4E7912BF47A96AE7DD7BAC0AADF2F744F4E9@SJEXCHCCR02.corp.ad.broadcom.com>
From: "Vladislav Zolotarov" <vladz@broadcom.com>
Date: Wed, 15 Jun 2011 04:57:09 -0700
> Dave, what do u want me to do now: do u want me to resend the series?
Not necessary, they are still queued up in patchwork.
^ permalink raw reply
* Re: tc match MAC destination
From: jamal @ 2011-06-15 14:51 UTC (permalink / raw)
To: ierdnah; +Cc: pdoru.kernel, netdev
In-Reply-To: <1308125523.30324.64.camel@ierdnac-hp>
On Wed, 2011-06-15 at 11:12 +0300, Andrei Popa wrote:
> Hello,
>
> I want to shape PVSTP+ traffic (traffic that has MAC destination
> 01:00:0c:cc:cc:cd) and it doesn't work.
> I've tried
> filter parent 1: protocol 802_3 pref 2 u32 fh 802::11 order 17 key ht
> 802 bkt 0 flowid 1:3
> match 01000ccc/ffffffff at 0
> but it doesn't work.
>
MAC addresses are at -ve offsets.
dst MAC starts at -14
src MAC at -8
ethertype at -2
Example:
#match my laptops MAC address ( 00:0b:97:97:4d:6a)
#for incoming packets on eth0 and count arp packets...
#
tc filter add dev eth0 parent ffff: protocol arp prio 10 u32 \
match u16 0x000B 0xffff at -14 \
match u32 0x97974D6A 0xffffffff at -12 \
match u16 0x0806 0xffff at -2 \
flowid 1:12 \
action ok
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next 0/24] bnx2x: New FW and support for 578xx
From: David Miller @ 2011-06-15 15:09 UTC (permalink / raw)
To: vladz; +Cc: mchan, bprakash, eilong, netdev, dmitry, yaniv.rosner, dwmw2
In-Reply-To: <201106141432.32257.vladz@broadcom.com>
From: "Vlad Zolotarov" <vladz@broadcom.com>
Date: Tue, 14 Jun 2011 14:32:31 +0300
> Dave, pls., consider applying this patch series.
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH net-next 0/8] tg3: Bugfixes and cleanups
From: David Miller @ 2011-06-15 15:19 UTC (permalink / raw)
To: mcarlson; +Cc: netdev
In-Reply-To: <1308008342-21030-1-git-send-email-mcarlson@broadcom.com>
From: "Matt Carlson" <mcarlson@broadcom.com>
Date: Mon, 13 Jun 2011 16:38:54 -0700
> This patchset commits a interrupt stall bugfix and a couple other minor cleanups.
All applied, thanks.
^ permalink raw reply
* [PATCH] tun: teach the tun/tap driver to support netpoll
From: Neil Horman @ 2011-06-15 15:25 UTC (permalink / raw)
To: netdev
Cc: Neil Horman, Rik van Riel, Maxim Krasnyansky, Cong Wang,
David S. Miller
Commit 8d8fc29d02a33e4bd5f4fa47823c1fd386346093 changed the behavior of slave
devices in regards to netpoll. Specifically it created a mutually exclusive
relationship between being a slave and a netpoll-capable device. This creates
problems for KVM because guests relied on needing netconsole active on a slave
device to a bridge. Ideally libvirtd could just attach netconsole to the bridge
device instead, but thats currently infeasible, because while the bridge device
supports netpoll, it requires that all slave interface also support it, but the
tun/tap driver currently does not. The most direct solution is to teach tun/tap
to support netpoll, which is implemented by the patch below.
I've not tested this yet, but its pretty straightforward.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reported-by: Rik van Riel <riel@redhat.com>
CC: Rik van Riel <riel@redhat.com>
CC: Maxim Krasnyansky <maxk@qualcomm.com>
CC: Cong Wang <amwang@redhat.com>
CC: "David S. Miller" <davem@davemloft.net>
---
drivers/net/tun.c | 24 +++++++++++++++++++++++-
1 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 4dab85e..9a6b382 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -460,7 +460,23 @@ static u32 tun_net_fix_features(struct net_device *dev, u32 features)
return (features & tun->set_features) | (features & ~TUN_USER_FEATURES);
}
-
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void tun_poll_controller(struct net_device *dev)
+{
+ /*
+ * Tun only receives frames when:
+ * 1) the char device endpoint gets data from user space
+ * 2) the tun socket gets a sendmsg call from user space
+ * Since both of those are syncronous operations, we are guaranteed
+ * never to have pending data when we poll for it
+ * so theres nothing to do here but return.
+ * We need this though so netpoll recognizes us as an interface that
+ * supports polling, which enables bridge devices in virt setups to
+ * still use netconsole
+ */
+ return;
+}
+#endif
static const struct net_device_ops tun_netdev_ops = {
.ndo_uninit = tun_net_uninit,
.ndo_open = tun_net_open,
@@ -468,6 +484,9 @@ static const struct net_device_ops tun_netdev_ops = {
.ndo_start_xmit = tun_net_xmit,
.ndo_change_mtu = tun_net_change_mtu,
.ndo_fix_features = tun_net_fix_features,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller = tun_poll_controller,
+#endif
};
static const struct net_device_ops tap_netdev_ops = {
@@ -480,6 +499,9 @@ static const struct net_device_ops tap_netdev_ops = {
.ndo_set_multicast_list = tun_net_mclist,
.ndo_set_mac_address = eth_mac_addr,
.ndo_validate_addr = eth_validate_addr,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller = tun_poll_controller,
+#endif
};
/* Initialize net device. */
--
1.7.5.4
^ permalink raw reply related
* Re: software iwarp stack update
From: Bernard Metzler @ 2011-06-15 15:43 UTC (permalink / raw)
To: Bart Van Assche
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <BANLkTikUWpf4iAQT-9DwL_qSCEcY7CPN6w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Bart, all,
after rebasing to davem/net-next-2.6.git, I formatted a patch adding
to the initial 'siw' driver posting from last October. Given the rather
substantial amount of changes and time elapsed, I am not sure if people
would better like a complete re-posting of all files.
If I don't hear objection before tomorrow I would post it as an
increment - as summarized below.
Many thanks for advice,
Bernard.
drivers/infiniband/hw/siw/Makefile | 2 +-
drivers/infiniband/hw/siw/iwarp.h | 100 +++++++++++++++++
+------------------
drivers/infiniband/hw/siw/siw.h | 128 +++++++++++++++++
+--------------------
drivers/infiniband/hw/siw/siw_main.c | 229 +++++++++++++++++++++++++++
+------
drivers/infiniband/hw/siw/siw_ae.c | 2 +-
drivers/infiniband/hw/siw/siw_verbs.c | 572 ++++++++++++++++++++
+------------
drivers/infiniband/hw/siw/siw_verbs.h | 3 +
drivers/infiniband/hw/siw/siw_cm.c | 1158 +++++++++++++++++
+------------------
drivers/infiniband/hw/siw/siw_cm.h | 38 +-
drivers/infiniband/hw/siw/siw_obj.c | 165 +++++++++++++
+---------------------
drivers/infiniband/hw/siw/siw_obj.h | 34 +++++++-
drivers/infiniband/hw/siw/siw_qp.c | 128 ++++++++++++++++++++
+---------------
drivers/infiniband/hw/siw/siw_cq.c | 24 ++++--------------------
drivers/infiniband/hw/siw/siw_qp_tx.c | 147 ++++++++++++++++++
+--------------
drivers/infiniband/hw/siw/siw_qp_rx.c | 234 ++++++++++++++++++++
+------------
Documentation/networking/siw.txt | 62 +++++++++++++++++++++++++
+-----------
drivers/infiniband/hw/siw/siw_mem.c | 178 +++++++++++++++++++++++++++++++
++++
linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org wrote on 06/04/2011 08:01:45 PM:
> On Wed, Sep 22, 2010 at 10:19 AM, Bernard Metzler <BMT-OA+xvbQnYDHMbYB6QlFGEg@public.gmane.org>
wrote:
> > Earlier this year, we announced the availability of an open source,
> > full software implementation of the iWARP RDMA protocol stack - see
> > my email "software iwarp stack" from March 14th at the linux-rdma list
> > (http://www.mail-archive.com/linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg02940.html)
> > While since then working on performance and stability, we provided
> > some source code updates. Current user and kernel code is available at
> > gitorious.org/softiwarp. Please see the CHANGES file in the
> > kernel/ directory for a summary of the most recent changes.
>
> (replying to an e-mail of about nine months ago)
>
> Hello Bernard,
>
> It has been pretty quiet recently around the "siw" driver. Have you
> had the chance to make any progress recently on this driver ?
>
> Thanks,
>
> Bart.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] virtio-net: per cpu 64 bit stats
From: Stephen Hemminger @ 2011-06-15 15:43 UTC (permalink / raw)
To: Rusty Russell, Michael S. Tsirkin; +Cc: virtualization, netdev
Use per-cpu variables to maintain 64 bit statistics.
Compile tested only.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/drivers/net/virtio_net.c 2011-06-14 15:18:46.448596355 -0400
+++ b/drivers/net/virtio_net.c 2011-06-15 09:54:22.914426067 -0400
@@ -40,6 +40,15 @@ module_param(gso, bool, 0444);
#define VIRTNET_SEND_COMMAND_SG_MAX 2
+struct virtnet_stats {
+ struct u64_stats_sync syncp;
+ u64 tx_bytes;
+ u64 tx_packets;
+
+ u64 rx_bytes;
+ u64 rx_packets;
+};
+
struct virtnet_info {
struct virtio_device *vdev;
struct virtqueue *rvq, *svq, *cvq;
@@ -56,6 +65,9 @@ struct virtnet_info {
/* Host will merge rx buffers for big packets (shake it! shake it!) */
bool mergeable_rx_bufs;
+ /* Active statistics */
+ struct virtnet_stats __percpu *stats;
+
/* Work struct for refilling if we run low on memory. */
struct delayed_work refill;
@@ -209,7 +221,6 @@ static int receive_mergeable(struct virt
skb->dev->stats.rx_length_errors++;
return -EINVAL;
}
-
page = virtqueue_get_buf(vi->rvq, &len);
if (!page) {
pr_debug("%s: rx error: %d buffers missing\n",
@@ -217,6 +228,7 @@ static int receive_mergeable(struct virt
skb->dev->stats.rx_length_errors++;
return -EINVAL;
}
+
if (len > PAGE_SIZE)
len = PAGE_SIZE;
@@ -230,6 +242,7 @@ static int receive_mergeable(struct virt
static void receive_buf(struct net_device *dev, void *buf, unsigned int len)
{
struct virtnet_info *vi = netdev_priv(dev);
+ struct virtnet_stats __percpu *stats = this_cpu_ptr(vi->stats);
struct sk_buff *skb;
struct page *page;
struct skb_vnet_hdr *hdr;
@@ -265,8 +278,11 @@ static void receive_buf(struct net_devic
hdr = skb_vnet_hdr(skb);
skb->truesize += skb->data_len;
- dev->stats.rx_bytes += skb->len;
- dev->stats.rx_packets++;
+
+ u64_stats_update_begin(&stats->syncp);
+ stats->rx_bytes += skb->len;
+ stats->rx_packets++;
+ u64_stats_update_begin(&stats->syncp);
if (hdr->hdr.flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) {
pr_debug("Needs csum!\n");
@@ -515,11 +531,16 @@ static unsigned int free_old_xmit_skbs(s
{
struct sk_buff *skb;
unsigned int len, tot_sgs = 0;
+ struct virtnet_stats __percpu *stats = this_cpu_ptr(vi->stats);
while ((skb = virtqueue_get_buf(vi->svq, &len)) != NULL) {
pr_debug("Sent skb %p\n", skb);
- vi->dev->stats.tx_bytes += skb->len;
- vi->dev->stats.tx_packets++;
+
+ u64_stats_update_begin(&stats->syncp);
+ stats->tx_bytes += skb->len;
+ stats->tx_packets++;
+ u64_stats_update_begin(&stats->syncp);
+
tot_sgs += skb_vnet_hdr(skb)->num_sg;
dev_kfree_skb_any(skb);
}
@@ -641,6 +662,40 @@ static int virtnet_set_mac_address(struc
return 0;
}
+static struct rtnl_link_stats64 *virtnet_stats(struct net_device *dev,
+ struct rtnl_link_stats64 *tot)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+ int cpu;
+ unsigned int start;
+
+ for_each_possible_cpu(cpu) {
+ struct virtnet_stats __percpu *stats
+ = per_cpu_ptr(vi->stats, cpu);
+ u64 tpackets, tbytes, rpackets, rbytes;
+
+ do {
+ start = u64_stats_fetch_begin(&stats->syncp);
+ tpackets = stats->tx_packets;
+ tbytes = stats->tx_bytes;
+ rpackets = stats->rx_packets;
+ rbytes = stats->rx_bytes;
+ } while (u64_stats_fetch_retry(&stats->syncp, start));
+
+ tot->rx_packets += rpackets;
+ tot->tx_packets += tpackets;
+ tot->rx_bytes += rbytes;
+ tot->tx_bytes += tbytes;
+ }
+
+ tot->tx_dropped = dev->stats.tx_dropped;
+ tot->rx_dropped = dev->stats.rx_dropped;
+ tot->rx_length_errors = dev->stats.rx_length_errors;
+ tot->rx_frame_errors = dev->stats.rx_frame_errors;
+
+ return tot;
+}
+
#ifdef CONFIG_NET_POLL_CONTROLLER
static void virtnet_netpoll(struct net_device *dev)
{
@@ -650,6 +705,14 @@ static void virtnet_netpoll(struct net_d
}
#endif
+static void virtnet_free(struct net_device *dev)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+
+ free_percpu(vi->stats);
+ free_netdev(dev);
+}
+
static int virtnet_open(struct net_device *dev)
{
struct virtnet_info *vi = netdev_priv(dev);
@@ -835,6 +898,7 @@ static const struct net_device_ops virtn
.ndo_set_mac_address = virtnet_set_mac_address,
.ndo_set_rx_mode = virtnet_set_rx_mode,
.ndo_change_mtu = virtnet_change_mtu,
+ .ndo_get_stats64 = virtnet_stats,
.ndo_vlan_rx_add_vid = virtnet_vlan_rx_add_vid,
.ndo_vlan_rx_kill_vid = virtnet_vlan_rx_kill_vid,
#ifdef CONFIG_NET_POLL_CONTROLLER
@@ -895,6 +959,8 @@ static int virtnet_probe(struct virtio_d
/* Set up network device as normal. */
dev->netdev_ops = &virtnet_netdev;
dev->features = NETIF_F_HIGHDMA;
+ dev->destructor = virtnet_free;
+
SET_ETHTOOL_OPS(dev, &virtnet_ethtool_ops);
SET_NETDEV_DEV(dev, &vdev->dev);
@@ -939,6 +1005,11 @@ static int virtnet_probe(struct virtio_d
vi->vdev = vdev;
vdev->priv = vi;
vi->pages = NULL;
+ vi->stats = alloc_percpu(struct virtnet_stats);
+ err = -ENOMEM;
+ if (vi->stats == NULL)
+ goto free;
+
INIT_DELAYED_WORK(&vi->refill, refill_work);
sg_init_table(vi->rx_sg, ARRAY_SIZE(vi->rx_sg));
sg_init_table(vi->tx_sg, ARRAY_SIZE(vi->tx_sg));
@@ -958,7 +1029,7 @@ static int virtnet_probe(struct virtio_d
err = vdev->config->find_vqs(vdev, nvqs, vqs, callbacks, names);
if (err)
- goto free;
+ goto free_stats;
vi->rvq = vqs[0];
vi->svq = vqs[1];
@@ -1003,6 +1074,8 @@ unregister:
cancel_delayed_work_sync(&vi->refill);
free_vqs:
vdev->config->del_vqs(vdev);
+free_stats:
+ free_percpu(vi->stats);
free:
free_netdev(dev);
return err;
^ permalink raw reply
* Re: [PATCH] virtio-net: per cpu 64 bit stats
From: Eric Dumazet @ 2011-06-15 15:58 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Rusty Russell, Michael S. Tsirkin, virtualization, netdev
In-Reply-To: <20110615114337.09fe62f6@s6510.ftrdhcpuser.net>
Le mercredi 15 juin 2011 à 11:43 -0400, Stephen Hemminger a écrit :
> Use per-cpu variables to maintain 64 bit statistics.
> Compile tested only.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> --- a/drivers/net/virtio_net.c 2011-06-14 15:18:46.448596355 -0400
> +++ b/drivers/net/virtio_net.c 2011-06-15 09:54:22.914426067 -0400
> @@ -40,6 +40,15 @@ module_param(gso, bool, 0444);
>
> #define VIRTNET_SEND_COMMAND_SG_MAX 2
>
> +struct virtnet_stats {
> + struct u64_stats_sync syncp;
> + u64 tx_bytes;
> + u64 tx_packets;
> +
> + u64 rx_bytes;
> + u64 rx_packets;
> +};
> +
> struct virtnet_info {
> struct virtio_device *vdev;
> struct virtqueue *rvq, *svq, *cvq;
> @@ -56,6 +65,9 @@ struct virtnet_info {
> /* Host will merge rx buffers for big packets (shake it! shake it!) */
> bool mergeable_rx_bufs;
>
> + /* Active statistics */
> + struct virtnet_stats __percpu *stats;
> +
> /* Work struct for refilling if we run low on memory. */
> struct delayed_work refill;
>
> @@ -209,7 +221,6 @@ static int receive_mergeable(struct virt
> skb->dev->stats.rx_length_errors++;
> return -EINVAL;
> }
> -
> page = virtqueue_get_buf(vi->rvq, &len);
> if (!page) {
> pr_debug("%s: rx error: %d buffers missing\n",
> @@ -217,6 +228,7 @@ static int receive_mergeable(struct virt
> skb->dev->stats.rx_length_errors++;
> return -EINVAL;
> }
> +
> if (len > PAGE_SIZE)
> len = PAGE_SIZE;
>
> @@ -230,6 +242,7 @@ static int receive_mergeable(struct virt
> static void receive_buf(struct net_device *dev, void *buf, unsigned int len)
> {
> struct virtnet_info *vi = netdev_priv(dev);
> + struct virtnet_stats __percpu *stats = this_cpu_ptr(vi->stats);
> struct sk_buff *skb;
> struct page *page;
> struct skb_vnet_hdr *hdr;
> @@ -265,8 +278,11 @@ static void receive_buf(struct net_devic
>
> hdr = skb_vnet_hdr(skb);
> skb->truesize += skb->data_len;
> - dev->stats.rx_bytes += skb->len;
> - dev->stats.rx_packets++;
> +
> + u64_stats_update_begin(&stats->syncp);
> + stats->rx_bytes += skb->len;
> + stats->rx_packets++;
> + u64_stats_update_begin(&stats->syncp);
u64_stats_update_end(&stats->syncp);
>
> if (hdr->hdr.flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) {
> pr_debug("Needs csum!\n");
> @@ -515,11 +531,16 @@ static unsigned int free_old_xmit_skbs(s
> {
> struct sk_buff *skb;
> unsigned int len, tot_sgs = 0;
> + struct virtnet_stats __percpu *stats = this_cpu_ptr(vi->stats);
>
> while ((skb = virtqueue_get_buf(vi->svq, &len)) != NULL) {
> pr_debug("Sent skb %p\n", skb);
> - vi->dev->stats.tx_bytes += skb->len;
> - vi->dev->stats.tx_packets++;
> +
> + u64_stats_update_begin(&stats->syncp);
> + stats->tx_bytes += skb->len;
> + stats->tx_packets++;
> + u64_stats_update_begin(&stats->syncp);
u64_stats_update_end(&stats->syncp);
> +
> tot_sgs += skb_vnet_hdr(skb)->num_sg;
> dev_kfree_skb_any(skb);
> }
> @@ -641,6 +662,40 @@ static int virtnet_set_mac_address(struc
> return 0;
> }
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 37172] New: Enabling 802.1q vlan causes some packets to be received with a vlan id of 64
From: Antoine Reversat @ 2011-06-15 16:13 UTC (permalink / raw)
To: Andrew Morton; +Cc: bugme-daemon, netdev, Patrick McHardy
In-Reply-To: <BANLkTi=Omr+oe3nMiqVeS+8tiSJnxONbhQ@mail.gmail.com>
I've tested 2.6.37.6 and 3.0.0-rc2 and the bug is still reproducible
in both kernels. I'll try a 2.6.36 to see if it was present in it too.
Has this been tested on other hardware ? I'm still unsure if it's a
driver issue or if it's something else.
On Tue, Jun 14, 2011 at 9:31 AM, Antoine Reversat <a.reversat@gmail.com> wrote:
> On Mon, Jun 13, 2011 at 7:43 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
>>
>> From which kernel version did we regress? Was 2.6.38 OK?
>
> I can confirm this bug is present in 2.6.38.6
>
> I'll try and see if I can reproduce it on a 2.6.37
>
^ permalink raw reply
* Re: software iwarp stack update
From: Bart Van Assche @ 2011-06-15 16:32 UTC (permalink / raw)
To: Bernard Metzler; +Cc: linux-rdma, linux-rdma-owner, netdev
In-Reply-To: <OFC721DC15.CBE893E3-ONC12578B0.0053737C-C12578B0.00565784@ch.ibm.com>
On Wed, Jun 15, 2011 at 5:43 PM, Bernard Metzler <BMT@zurich.ibm.com> wrote:
> after rebasing to davem/net-next-2.6.git, I formatted a patch adding
> to the initial 'siw' driver posting from last October. Given the rather
> substantial amount of changes and time elapsed, I am not sure if people
> would better like a complete re-posting of all files.
> If I don't hear objection before tomorrow I would post it as an
> increment - as summarized below.
IMHO reposting the entire driver makes reviewing easier.
And please address checkpatch and sparse complaints before reposting.
The code currently available at gitorious triggers several easy to
address checkpatch and spare complaints:
$ cd softiwarp
$ convert-file-to-patch *[ch] |
/usr/src/torvalds-2.6.git/scripts/checkpatch.pl - -notree -nosignoff |
grep -E '^ERROR|^WARNING' | grep -v LINUX_VERSION_CODE | sort | uniq
-c | sort -rn
10 ERROR: spaces required around that '?' (ctx:VxV)
8 ERROR: spaces required around that ':' (ctx:VxV)
3 ERROR: spaces required around that ':' (ctx:VxW)
2 ERROR: Macros with complex values should be enclosed in parenthesis
1 WARNING: line over 80 characters
1 ERROR: trailing whitespace
$ LC_ALL=C make C=2 | grep warning
/home/bart/software/softiwarp/softiwarp/siw_main.c:73:10: warning:
symbol 'siw_num_cep' was not declared. Should it be static?
/home/bart/software/softiwarp/softiwarp/siw_verbs.c:1417:14: warning:
symbol 'siw_reg_phys_mr' was not declared. Should it be static?
/home/bart/software/softiwarp/softiwarp/siw_mem.c:164:27: warning:
symbol 'siw_dma_mapping_ops' was not declared. Should it be static?
Bart.
^ permalink raw reply
* Re: [PATCH] virtio-net: per cpu 64 bit stats (v2)
From: Stephen Hemminger @ 2011-06-15 16:36 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Rusty Russell, Michael S. Tsirkin, virtualization, netdev
In-Reply-To: <1308153538.3128.3.camel@edumazet-laptop>
Use per-cpu variables to maintain 64 bit statistics.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/drivers/net/virtio_net.c 2011-06-14 15:18:46.448596355 -0400
+++ b/drivers/net/virtio_net.c 2011-06-15 12:02:54.860667443 -0400
@@ -40,6 +40,15 @@ module_param(gso, bool, 0444);
#define VIRTNET_SEND_COMMAND_SG_MAX 2
+struct virtnet_stats {
+ struct u64_stats_sync syncp;
+ u64 tx_bytes;
+ u64 tx_packets;
+
+ u64 rx_bytes;
+ u64 rx_packets;
+};
+
struct virtnet_info {
struct virtio_device *vdev;
struct virtqueue *rvq, *svq, *cvq;
@@ -56,6 +65,9 @@ struct virtnet_info {
/* Host will merge rx buffers for big packets (shake it! shake it!) */
bool mergeable_rx_bufs;
+ /* Active statistics */
+ struct virtnet_stats __percpu *stats;
+
/* Work struct for refilling if we run low on memory. */
struct delayed_work refill;
@@ -209,7 +221,6 @@ static int receive_mergeable(struct virt
skb->dev->stats.rx_length_errors++;
return -EINVAL;
}
-
page = virtqueue_get_buf(vi->rvq, &len);
if (!page) {
pr_debug("%s: rx error: %d buffers missing\n",
@@ -217,6 +228,7 @@ static int receive_mergeable(struct virt
skb->dev->stats.rx_length_errors++;
return -EINVAL;
}
+
if (len > PAGE_SIZE)
len = PAGE_SIZE;
@@ -230,6 +242,7 @@ static int receive_mergeable(struct virt
static void receive_buf(struct net_device *dev, void *buf, unsigned int len)
{
struct virtnet_info *vi = netdev_priv(dev);
+ struct virtnet_stats __percpu *stats = this_cpu_ptr(vi->stats);
struct sk_buff *skb;
struct page *page;
struct skb_vnet_hdr *hdr;
@@ -265,8 +278,11 @@ static void receive_buf(struct net_devic
hdr = skb_vnet_hdr(skb);
skb->truesize += skb->data_len;
- dev->stats.rx_bytes += skb->len;
- dev->stats.rx_packets++;
+
+ u64_stats_update_begin(&stats->syncp);
+ stats->rx_bytes += skb->len;
+ stats->rx_packets++;
+ u64_stats_update_end(&stats->syncp);
if (hdr->hdr.flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) {
pr_debug("Needs csum!\n");
@@ -515,11 +531,16 @@ static unsigned int free_old_xmit_skbs(s
{
struct sk_buff *skb;
unsigned int len, tot_sgs = 0;
+ struct virtnet_stats __percpu *stats = this_cpu_ptr(vi->stats);
while ((skb = virtqueue_get_buf(vi->svq, &len)) != NULL) {
pr_debug("Sent skb %p\n", skb);
- vi->dev->stats.tx_bytes += skb->len;
- vi->dev->stats.tx_packets++;
+
+ u64_stats_update_begin(&stats->syncp);
+ stats->tx_bytes += skb->len;
+ stats->tx_packets++;
+ u64_stats_update_end(&stats->syncp);
+
tot_sgs += skb_vnet_hdr(skb)->num_sg;
dev_kfree_skb_any(skb);
}
@@ -641,6 +662,40 @@ static int virtnet_set_mac_address(struc
return 0;
}
+static struct rtnl_link_stats64 *virtnet_stats(struct net_device *dev,
+ struct rtnl_link_stats64 *tot)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+ int cpu;
+ unsigned int start;
+
+ for_each_possible_cpu(cpu) {
+ struct virtnet_stats __percpu *stats
+ = per_cpu_ptr(vi->stats, cpu);
+ u64 tpackets, tbytes, rpackets, rbytes;
+
+ do {
+ start = u64_stats_fetch_begin(&stats->syncp);
+ tpackets = stats->tx_packets;
+ tbytes = stats->tx_bytes;
+ rpackets = stats->rx_packets;
+ rbytes = stats->rx_bytes;
+ } while (u64_stats_fetch_retry(&stats->syncp, start));
+
+ tot->rx_packets += rpackets;
+ tot->tx_packets += tpackets;
+ tot->rx_bytes += rbytes;
+ tot->tx_bytes += tbytes;
+ }
+
+ tot->tx_dropped = dev->stats.tx_dropped;
+ tot->rx_dropped = dev->stats.rx_dropped;
+ tot->rx_length_errors = dev->stats.rx_length_errors;
+ tot->rx_frame_errors = dev->stats.rx_frame_errors;
+
+ return tot;
+}
+
#ifdef CONFIG_NET_POLL_CONTROLLER
static void virtnet_netpoll(struct net_device *dev)
{
@@ -650,6 +705,14 @@ static void virtnet_netpoll(struct net_d
}
#endif
+static void virtnet_free(struct net_device *dev)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+
+ free_percpu(vi->stats);
+ free_netdev(dev);
+}
+
static int virtnet_open(struct net_device *dev)
{
struct virtnet_info *vi = netdev_priv(dev);
@@ -835,6 +898,7 @@ static const struct net_device_ops virtn
.ndo_set_mac_address = virtnet_set_mac_address,
.ndo_set_rx_mode = virtnet_set_rx_mode,
.ndo_change_mtu = virtnet_change_mtu,
+ .ndo_get_stats64 = virtnet_stats,
.ndo_vlan_rx_add_vid = virtnet_vlan_rx_add_vid,
.ndo_vlan_rx_kill_vid = virtnet_vlan_rx_kill_vid,
#ifdef CONFIG_NET_POLL_CONTROLLER
@@ -895,6 +959,8 @@ static int virtnet_probe(struct virtio_d
/* Set up network device as normal. */
dev->netdev_ops = &virtnet_netdev;
dev->features = NETIF_F_HIGHDMA;
+ dev->destructor = virtnet_free;
+
SET_ETHTOOL_OPS(dev, &virtnet_ethtool_ops);
SET_NETDEV_DEV(dev, &vdev->dev);
@@ -939,6 +1005,11 @@ static int virtnet_probe(struct virtio_d
vi->vdev = vdev;
vdev->priv = vi;
vi->pages = NULL;
+ vi->stats = alloc_percpu(struct virtnet_stats);
+ err = -ENOMEM;
+ if (vi->stats == NULL)
+ goto free;
+
INIT_DELAYED_WORK(&vi->refill, refill_work);
sg_init_table(vi->rx_sg, ARRAY_SIZE(vi->rx_sg));
sg_init_table(vi->tx_sg, ARRAY_SIZE(vi->tx_sg));
@@ -958,7 +1029,7 @@ static int virtnet_probe(struct virtio_d
err = vdev->config->find_vqs(vdev, nvqs, vqs, callbacks, names);
if (err)
- goto free;
+ goto free_stats;
vi->rvq = vqs[0];
vi->svq = vqs[1];
@@ -1003,6 +1074,8 @@ unregister:
cancel_delayed_work_sync(&vi->refill);
free_vqs:
vdev->config->del_vqs(vdev);
+free_stats:
+ free_percpu(vi->stats);
free:
free_netdev(dev);
return err;
^ permalink raw reply
* Re: [Bugme-new] [Bug 37172] New: Enabling 802.1q vlan causes some packets to be received with a vlan id of 64
From: Antoine Reversat @ 2011-06-15 16:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: bugme-daemon, netdev, Patrick McHardy
In-Reply-To: <BANLkTikU=78h1BcVm7akgE3PxRP5eb57gw@mail.gmail.com>
On Wed, Jun 15, 2011 at 12:13 PM, Antoine Reversat <a.reversat@gmail.com> wrote:
> I've tested 2.6.37.6 and 3.0.0-rc2 and the bug is still reproducible
> in both kernels. I'll try a 2.6.36 to see if it was present in it too.
>
> Has this been tested on other hardware ? I'm still unsure if it's a
> driver issue or if it's something else.
>
Infact it's probably a driver bug : I've tried on a coworkers computer
with a different network adapter and it works flawlessly. I'll contact
the forcedeth people about this.
^ permalink raw reply
* Re: [PATCH] tun: teach the tun/tap driver to support netpoll
From: Rik van Riel @ 2011-06-15 17:50 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, Maxim Krasnyansky, Cong Wang, David S. Miller
In-Reply-To: <1308151501-8434-1-git-send-email-nhorman@tuxdriver.com>
On 06/15/2011 11:25 AM, Neil Horman wrote:
> Commit 8d8fc29d02a33e4bd5f4fa47823c1fd386346093 changed the behavior of slave
> devices in regards to netpoll. Specifically it created a mutually exclusive
> relationship between being a slave and a netpoll-capable device. This creates
> problems for KVM because guests relied on needing netconsole active on a slave
> device to a bridge. Ideally libvirtd could just attach netconsole to the bridge
> device instead, but thats currently infeasible, because while the bridge device
> supports netpoll, it requires that all slave interface also support it, but the
> tun/tap driver currently does not. The most direct solution is to teach tun/tap
> to support netpoll, which is implemented by the patch below.
>
> I've not tested this yet, but its pretty straightforward.
I have tested it. I can run netconsole and my KVM guests
simultaneously again.
Thank you, Neil!
Now all I have to do is log whatever other bugs are haunting
3.0-rc and causing my system to hang :)
> Signed-off-by: Neil Horman<nhorman@tuxdriver.com>
> Reported-by: Rik van Riel<riel@redhat.com>
> CC: Rik van Riel<riel@redhat.com>
> CC: Maxim Krasnyansky<maxk@qualcomm.com>
> CC: Cong Wang<amwang@redhat.com>
> CC: "David S. Miller"<davem@davemloft.net>
Reviewed-by: Rik van Riel <riel@redhat.com>
Tested-by: Rik van Riel <riel@redhat.com>
--
All rights reversed
^ permalink raw reply
* Re: software iwarp stack update
From: Roland Dreier @ 2011-06-15 18:11 UTC (permalink / raw)
To: Bart Van Assche
Cc: Bernard Metzler, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <BANLkTimmxN71ihGGXPH3JB1vGWyv1p-7mw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Jun 15, 2011 at 9:32 AM, Bart Van Assche <bvanassche-HInyCGIudOg@public.gmane.org> wrote:
> IMHO reposting the entire driver makes reviewing easier.
Yes, I agree. I don't think anyone is familiar enough with the
original version,
so an incremental patch is not particularly enlightening.
> And please address checkpatch and sparse complaints before reposting.
Right. It's always best to take care of the trivial easy stuff first, to let
people focus on real issues.
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] virtio-net: per cpu 64 bit stats
From: Michael S. Tsirkin @ 2011-06-15 18:33 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Rusty Russell, virtualization, netdev
In-Reply-To: <20110615114337.09fe62f6@s6510.ftrdhcpuser.net>
On Wed, Jun 15, 2011 at 11:43:37AM -0400, Stephen Hemminger wrote:
> Use per-cpu variables to maintain 64 bit statistics.
> Compile tested only.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Interesting. Does this help speed at all?
> --- a/drivers/net/virtio_net.c 2011-06-14 15:18:46.448596355 -0400
> +++ b/drivers/net/virtio_net.c 2011-06-15 09:54:22.914426067 -0400
> @@ -40,6 +40,15 @@ module_param(gso, bool, 0444);
>
> #define VIRTNET_SEND_COMMAND_SG_MAX 2
>
> +struct virtnet_stats {
> + struct u64_stats_sync syncp;
> + u64 tx_bytes;
> + u64 tx_packets;
> +
> + u64 rx_bytes;
> + u64 rx_packets;
> +};
> +
> struct virtnet_info {
> struct virtio_device *vdev;
> struct virtqueue *rvq, *svq, *cvq;
> @@ -56,6 +65,9 @@ struct virtnet_info {
> /* Host will merge rx buffers for big packets (shake it! shake it!) */
> bool mergeable_rx_bufs;
>
> + /* Active statistics */
> + struct virtnet_stats __percpu *stats;
> +
> /* Work struct for refilling if we run low on memory. */
> struct delayed_work refill;
>
> @@ -209,7 +221,6 @@ static int receive_mergeable(struct virt
> skb->dev->stats.rx_length_errors++;
> return -EINVAL;
> }
> -
> page = virtqueue_get_buf(vi->rvq, &len);
> if (!page) {
> pr_debug("%s: rx error: %d buffers missing\n",
> @@ -217,6 +228,7 @@ static int receive_mergeable(struct virt
> skb->dev->stats.rx_length_errors++;
> return -EINVAL;
> }
> +
> if (len > PAGE_SIZE)
> len = PAGE_SIZE;
>
Let's not tweak whitespace unnecessarily.
> @@ -230,6 +242,7 @@ static int receive_mergeable(struct virt
> static void receive_buf(struct net_device *dev, void *buf, unsigned int len)
> {
> struct virtnet_info *vi = netdev_priv(dev);
> + struct virtnet_stats __percpu *stats = this_cpu_ptr(vi->stats);
> struct sk_buff *skb;
> struct page *page;
> struct skb_vnet_hdr *hdr;
> @@ -265,8 +278,11 @@ static void receive_buf(struct net_devic
>
> hdr = skb_vnet_hdr(skb);
> skb->truesize += skb->data_len;
> - dev->stats.rx_bytes += skb->len;
> - dev->stats.rx_packets++;
> +
> + u64_stats_update_begin(&stats->syncp);
> + stats->rx_bytes += skb->len;
> + stats->rx_packets++;
> + u64_stats_update_begin(&stats->syncp);
>
> if (hdr->hdr.flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) {
> pr_debug("Needs csum!\n");
> @@ -515,11 +531,16 @@ static unsigned int free_old_xmit_skbs(s
> {
> struct sk_buff *skb;
> unsigned int len, tot_sgs = 0;
> + struct virtnet_stats __percpu *stats = this_cpu_ptr(vi->stats);
>
> while ((skb = virtqueue_get_buf(vi->svq, &len)) != NULL) {
> pr_debug("Sent skb %p\n", skb);
> - vi->dev->stats.tx_bytes += skb->len;
> - vi->dev->stats.tx_packets++;
> +
> + u64_stats_update_begin(&stats->syncp);
> + stats->tx_bytes += skb->len;
> + stats->tx_packets++;
> + u64_stats_update_begin(&stats->syncp);
> +
> tot_sgs += skb_vnet_hdr(skb)->num_sg;
> dev_kfree_skb_any(skb);
> }
> @@ -641,6 +662,40 @@ static int virtnet_set_mac_address(struc
> return 0;
> }
>
> +static struct rtnl_link_stats64 *virtnet_stats(struct net_device *dev,
> + struct rtnl_link_stats64 *tot)
> +{
> + struct virtnet_info *vi = netdev_priv(dev);
> + int cpu;
> + unsigned int start;
> +
> + for_each_possible_cpu(cpu) {
> + struct virtnet_stats __percpu *stats
> + = per_cpu_ptr(vi->stats, cpu);
> + u64 tpackets, tbytes, rpackets, rbytes;
> +
> + do {
> + start = u64_stats_fetch_begin(&stats->syncp);
> + tpackets = stats->tx_packets;
> + tbytes = stats->tx_bytes;
> + rpackets = stats->rx_packets;
> + rbytes = stats->rx_bytes;
> + } while (u64_stats_fetch_retry(&stats->syncp, start));
> +
> + tot->rx_packets += rpackets;
> + tot->tx_packets += tpackets;
> + tot->rx_bytes += rbytes;
> + tot->tx_bytes += tbytes;
> + }
> +
> + tot->tx_dropped = dev->stats.tx_dropped;
> + tot->rx_dropped = dev->stats.rx_dropped;
> + tot->rx_length_errors = dev->stats.rx_length_errors;
> + tot->rx_frame_errors = dev->stats.rx_frame_errors;
> +
> + return tot;
> +}
> +
> #ifdef CONFIG_NET_POLL_CONTROLLER
> static void virtnet_netpoll(struct net_device *dev)
> {
> @@ -650,6 +705,14 @@ static void virtnet_netpoll(struct net_d
> }
> #endif
>
> +static void virtnet_free(struct net_device *dev)
> +{
> + struct virtnet_info *vi = netdev_priv(dev);
> +
> + free_percpu(vi->stats);
> + free_netdev(dev);
> +}
> +
> static int virtnet_open(struct net_device *dev)
> {
> struct virtnet_info *vi = netdev_priv(dev);
> @@ -835,6 +898,7 @@ static const struct net_device_ops virtn
> .ndo_set_mac_address = virtnet_set_mac_address,
> .ndo_set_rx_mode = virtnet_set_rx_mode,
> .ndo_change_mtu = virtnet_change_mtu,
> + .ndo_get_stats64 = virtnet_stats,
> .ndo_vlan_rx_add_vid = virtnet_vlan_rx_add_vid,
> .ndo_vlan_rx_kill_vid = virtnet_vlan_rx_kill_vid,
> #ifdef CONFIG_NET_POLL_CONTROLLER
> @@ -895,6 +959,8 @@ static int virtnet_probe(struct virtio_d
> /* Set up network device as normal. */
> dev->netdev_ops = &virtnet_netdev;
> dev->features = NETIF_F_HIGHDMA;
> + dev->destructor = virtnet_free;
> +
> SET_ETHTOOL_OPS(dev, &virtnet_ethtool_ops);
> SET_NETDEV_DEV(dev, &vdev->dev);
>
> @@ -939,6 +1005,11 @@ static int virtnet_probe(struct virtio_d
> vi->vdev = vdev;
> vdev->priv = vi;
> vi->pages = NULL;
> + vi->stats = alloc_percpu(struct virtnet_stats);
> + err = -ENOMEM;
> + if (vi->stats == NULL)
> + goto free;
> +
> INIT_DELAYED_WORK(&vi->refill, refill_work);
> sg_init_table(vi->rx_sg, ARRAY_SIZE(vi->rx_sg));
> sg_init_table(vi->tx_sg, ARRAY_SIZE(vi->tx_sg));
> @@ -958,7 +1029,7 @@ static int virtnet_probe(struct virtio_d
>
> err = vdev->config->find_vqs(vdev, nvqs, vqs, callbacks, names);
> if (err)
> - goto free;
> + goto free_stats;
>
> vi->rvq = vqs[0];
> vi->svq = vqs[1];
> @@ -1003,6 +1074,8 @@ unregister:
> cancel_delayed_work_sync(&vi->refill);
> free_vqs:
> vdev->config->del_vqs(vdev);
> +free_stats:
> + free_percpu(vi->stats);
> free:
> free_netdev(dev);
> return err;
^ 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