* [PATCH v2 5/7] per-netns ipv4 sysctl_tcp_mem
From: Glauber Costa @ 2011-09-15 1:46 UTC (permalink / raw)
To: linux-kernel
Cc: paul, lizf, kamezawa.hiroyu, ebiederm, davem, gthelen, netdev,
linux-mm, Glauber Costa
In-Reply-To: <1316051175-17780-1-git-send-email-glommer@parallels.com>
This patch allows each namespace to independently set up
its levels for tcp memory pressure thresholds. This patch
alone does not buy much: we need to make this values
per group of process somehow. This is achieved in the
patches that follows in this patchset.
Signed-off-by: Glauber Costa <glommer@parallels.com>
CC: David S. Miller <davem@davemloft.net>
CC: Hiroyouki Kamezawa <kamezawa.hiroyu@jp.fujitsu.com>
CC: Eric W. Biederman <ebiederm@xmission.com>
---
include/net/netns/ipv4.h | 1 +
include/net/tcp.h | 1 -
mm/memcontrol.c | 9 +++++--
net/ipv4/sysctl_net_ipv4.c | 51 +++++++++++++++++++++++++++++++++++++------
net/ipv4/tcp.c | 13 ++--------
5 files changed, 54 insertions(+), 21 deletions(-)
diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
index d786b4f..bbd023a 100644
--- a/include/net/netns/ipv4.h
+++ b/include/net/netns/ipv4.h
@@ -55,6 +55,7 @@ struct netns_ipv4 {
int current_rt_cache_rebuild_count;
unsigned int sysctl_ping_group_range[2];
+ long sysctl_tcp_mem[3];
atomic_t rt_genid;
atomic_t dev_addr_genid;
diff --git a/include/net/tcp.h b/include/net/tcp.h
index ce3c211..257e1f9 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -231,7 +231,6 @@ extern int sysctl_tcp_fack;
extern int sysctl_tcp_reordering;
extern int sysctl_tcp_ecn;
extern int sysctl_tcp_dsack;
-extern long sysctl_tcp_mem[3];
extern int sysctl_tcp_wmem[3];
extern int sysctl_tcp_rmem[3];
extern int sysctl_tcp_app_win;
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 7db430c..039cb79 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -358,6 +358,8 @@ static struct mem_cgroup *parent_mem_cgroup(struct mem_cgroup *mem);
#ifdef CONFIG_INET
#include <net/tcp.h>
#include <net/ip.h>
+#include <linux/nsproxy.h>
+
void memcg_sock_mem_alloc(struct mem_cgroup *mem, struct proto *prot,
int amt, int *parent_failure)
{
@@ -470,6 +472,7 @@ int tcp_init_cgroup(struct proto *prot, struct cgroup *cgrp,
{
struct mem_cgroup *cg = mem_cgroup_from_cont(cgrp);
unsigned long limit;
+ struct net *net = current->nsproxy->net_ns;
cg->tcp_memory_pressure = 0;
atomic_long_set(&cg->tcp_memory_allocated, 0);
@@ -478,9 +481,9 @@ int tcp_init_cgroup(struct proto *prot, struct cgroup *cgrp,
limit = nr_free_buffer_pages() / 8;
limit = max(limit, 128UL);
- cg->tcp_prot_mem[0] = sysctl_tcp_mem[0];
- cg->tcp_prot_mem[1] = sysctl_tcp_mem[1];
- cg->tcp_prot_mem[2] = sysctl_tcp_mem[2];
+ cg->tcp_prot_mem[0] = net->ipv4.sysctl_tcp_mem[0];
+ cg->tcp_prot_mem[1] = net->ipv4.sysctl_tcp_mem[1];
+ cg->tcp_prot_mem[2] = net->ipv4.sysctl_tcp_mem[2];
tcp_init_cgroup_fill(prot, cgrp, ss);
return 0;
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 69fd720..bbd67ab 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -14,6 +14,7 @@
#include <linux/init.h>
#include <linux/slab.h>
#include <linux/nsproxy.h>
+#include <linux/swap.h>
#include <net/snmp.h>
#include <net/icmp.h>
#include <net/ip.h>
@@ -174,6 +175,36 @@ static int proc_allowed_congestion_control(ctl_table *ctl,
return ret;
}
+static int ipv4_tcp_mem(ctl_table *ctl, int write,
+ void __user *buffer, size_t *lenp,
+ loff_t *ppos)
+{
+ int ret;
+ unsigned long vec[3];
+ struct net *net = current->nsproxy->net_ns;
+
+ ctl_table tmp = {
+ .data = &vec,
+ .maxlen = sizeof(vec),
+ .mode = ctl->mode,
+ };
+
+ if (!write) {
+ ctl->data = &net->ipv4.sysctl_tcp_mem;
+ return proc_doulongvec_minmax(ctl, write, buffer, lenp, ppos);
+ }
+
+ ret = proc_doulongvec_minmax(&tmp, write, buffer, lenp, ppos);
+ if (ret)
+ return ret;
+
+ net->ipv4.sysctl_tcp_mem[0] = vec[0];
+ net->ipv4.sysctl_tcp_mem[1] = vec[1];
+ net->ipv4.sysctl_tcp_mem[2] = vec[2];
+
+ return 0;
+}
+
static struct ctl_table ipv4_table[] = {
{
.procname = "tcp_timestamps",
@@ -433,13 +464,6 @@ static struct ctl_table ipv4_table[] = {
.proc_handler = proc_dointvec
},
{
- .procname = "tcp_mem",
- .data = &sysctl_tcp_mem,
- .maxlen = sizeof(sysctl_tcp_mem),
- .mode = 0644,
- .proc_handler = proc_doulongvec_minmax
- },
- {
.procname = "tcp_wmem",
.data = &sysctl_tcp_wmem,
.maxlen = sizeof(sysctl_tcp_wmem),
@@ -721,6 +745,12 @@ static struct ctl_table ipv4_net_table[] = {
.mode = 0644,
.proc_handler = ipv4_ping_group_range,
},
+ {
+ .procname = "tcp_mem",
+ .maxlen = sizeof(init_net.ipv4.sysctl_tcp_mem),
+ .mode = 0644,
+ .proc_handler = ipv4_tcp_mem,
+ },
{ }
};
@@ -734,6 +764,7 @@ EXPORT_SYMBOL_GPL(net_ipv4_ctl_path);
static __net_init int ipv4_sysctl_init_net(struct net *net)
{
struct ctl_table *table;
+ unsigned long limit;
table = ipv4_net_table;
if (!net_eq(net, &init_net)) {
@@ -769,6 +800,12 @@ static __net_init int ipv4_sysctl_init_net(struct net *net)
net->ipv4.sysctl_rt_cache_rebuild_count = 4;
+ limit = nr_free_buffer_pages() / 8;
+ limit = max(limit, 128UL);
+ net->ipv4.sysctl_tcp_mem[0] = limit / 4 * 3;
+ net->ipv4.sysctl_tcp_mem[1] = limit;
+ net->ipv4.sysctl_tcp_mem[2] = net->ipv4.sysctl_tcp_mem[0] * 2;
+
net->ipv4.ipv4_hdr = register_net_sysctl_table(net,
net_ipv4_ctl_path, table);
if (net->ipv4.ipv4_hdr == NULL)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 156b836..a94a0f1 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -282,11 +282,9 @@ int sysctl_tcp_fin_timeout __read_mostly = TCP_FIN_TIMEOUT;
struct percpu_counter tcp_orphan_count;
EXPORT_SYMBOL_GPL(tcp_orphan_count);
-long sysctl_tcp_mem[3] __read_mostly;
int sysctl_tcp_wmem[3] __read_mostly;
int sysctl_tcp_rmem[3] __read_mostly;
-EXPORT_SYMBOL(sysctl_tcp_mem);
EXPORT_SYMBOL(sysctl_tcp_rmem);
EXPORT_SYMBOL(sysctl_tcp_wmem);
@@ -333,7 +331,7 @@ EXPORT_SYMBOL(tcp_enter_memory_pressure_nocg);
long *tcp_sysctl_mem_nocg(struct mem_cgroup *sg)
{
- return sysctl_tcp_mem;
+ return init_net.ipv4.sysctl_tcp_mem;
}
EXPORT_SYMBOL(tcp_sysctl_mem_nocg);
@@ -3296,14 +3294,9 @@ void __init tcp_init(void)
sysctl_tcp_max_orphans = cnt / 2;
sysctl_max_syn_backlog = max(128, cnt / 256);
- limit = nr_free_buffer_pages() / 8;
- limit = max(limit, 128UL);
- sysctl_tcp_mem[0] = limit / 4 * 3;
- sysctl_tcp_mem[1] = limit;
- sysctl_tcp_mem[2] = sysctl_tcp_mem[0] * 2;
-
/* Set per-socket limits to no more than 1/128 the pressure threshold */
- limit = ((unsigned long)sysctl_tcp_mem[1]) << (PAGE_SHIFT - 7);
+ limit = ((unsigned long)init_net.ipv4.sysctl_tcp_mem[1])
+ << (PAGE_SHIFT - 7);
max_share = min(4UL*1024*1024, limit);
sysctl_tcp_wmem[0] = SK_MEM_QUANTUM;
--
1.7.6
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH v2 6/7] tcp buffer limitation: per-cgroup limit
From: Glauber Costa @ 2011-09-15 1:46 UTC (permalink / raw)
To: linux-kernel
Cc: paul, lizf, kamezawa.hiroyu, ebiederm, davem, gthelen, netdev,
linux-mm, Glauber Costa
In-Reply-To: <1316051175-17780-1-git-send-email-glommer@parallels.com>
This patch uses the "tcp_max_mem" field of the kmem_cgroup to
effectively control the amount of kernel memory pinned by a cgroup.
We have to make sure that none of the memory pressure thresholds
specified in the namespace are bigger than the current cgroup.
Signed-off-by: Glauber Costa <glommer@parallels.com>
CC: David S. Miller <davem@davemloft.net>
CC: Hiroyouki Kamezawa <kamezawa.hiroyu@jp.fujitsu.com>
CC: Eric W. Biederman <ebiederm@xmission.com>
---
Documentation/cgroups/memory.txt | 1 +
include/linux/memcontrol.h | 11 ++++++
mm/memcontrol.c | 69 +++++++++++++++++++++++++++++++++++++-
net/ipv4/sysctl_net_ipv4.c | 20 +++++++++++
4 files changed, 100 insertions(+), 1 deletions(-)
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
index ca58eff..ce825ee 100644
--- a/Documentation/cgroups/memory.txt
+++ b/Documentation/cgroups/memory.txt
@@ -78,6 +78,7 @@ Brief summary of control files.
memory.independent_kmem_limit # select whether or not kernel memory limits are
independent of user limits
+ memory.kmem.tcp.max_memory # set/show hard limit for tcp buf memory
1. History
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 47e05ba..a859399 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -439,6 +439,10 @@ static inline void sock_release_memcg(struct sock *sk)
{
cgroup_release_and_wakeup_rmdir(mem_cgroup_css(sk->sk_cgrp));
}
+
+unsigned long tcp_max_memory(struct mem_cgroup *cg);
+void tcp_prot_mem(struct mem_cgroup *cg, long val, int idx);
+
#else
/* memcontrol includes sockets.h, that includes memcontrol.h ... */
static inline void memcg_sock_mem_alloc(struct mem_cgroup *mem,
@@ -466,6 +470,13 @@ static inline void sock_update_memcg(struct sock *sk)
static inline void sock_release_memcg(struct sock *sk)
{
}
+static inline unsigned long tcp_max_memory(struct mem_cgroup *cg)
+{
+ return 0;
+}
+static inline void tcp_prot_mem(struct mem_cgroup *cg, long val, int idx)
+{
+}
#endif /* CONFIG_CGROUP_MEM_RES_CTLR_KMEM */
#endif /* CONFIG_INET */
#endif /* _LINUX_MEMCONTROL_H */
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 039cb79..b48e517 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -345,6 +345,7 @@ struct mem_cgroup {
spinlock_t pcp_counter_lock;
/* per-cgroup tcp memory pressure knobs */
+ int tcp_max_memory;
atomic_long_t tcp_memory_allocated;
struct percpu_counter tcp_sockets_allocated;
/* those two are read-mostly, leave them at the end */
@@ -439,6 +440,56 @@ struct percpu_counter *sockets_allocated_tcp(struct mem_cgroup *sg)
return &sg->tcp_sockets_allocated;
}
+static int tcp_write_maxmem(struct cgroup *cgrp, struct cftype *cft, u64 val)
+{
+ struct mem_cgroup *sg = mem_cgroup_from_cont(cgrp);
+ struct mem_cgroup *parent = parent_mem_cgroup(sg);
+ struct net *net = current->nsproxy->net_ns;
+ int i;
+
+ if (!cgroup_lock_live_group(cgrp))
+ return -ENODEV;
+
+ /*
+ * We can't allow more memory than our parents. Since this
+ * will be tested for all calls, by induction, there is no need
+ * to test any parent other than our own
+ * */
+ if (parent && (val > parent->tcp_max_memory))
+ val = parent->tcp_max_memory;
+
+ sg->tcp_max_memory = val;
+
+ for (i = 0; i < 3; i++)
+ sg->tcp_prot_mem[i] = min_t(long, val,
+ net->ipv4.sysctl_tcp_mem[i]);
+
+ cgroup_unlock();
+
+ return 0;
+}
+
+static u64 tcp_read_maxmem(struct cgroup *cgrp, struct cftype *cft)
+{
+ struct mem_cgroup *sg = mem_cgroup_from_cont(cgrp);
+ u64 ret;
+
+ if (!cgroup_lock_live_group(cgrp))
+ return -ENODEV;
+ ret = sg->tcp_max_memory;
+
+ cgroup_unlock();
+ return ret;
+}
+
+static struct cftype tcp_files[] = {
+ {
+ .name = "kmem.tcp.max_memory",
+ .write_u64 = tcp_write_maxmem,
+ .read_u64 = tcp_read_maxmem,
+ },
+};
+
/*
* For ipv6, we only need to fill in the function pointers (can't initialize
* things twice). So keep it separated
@@ -471,6 +522,7 @@ int tcp_init_cgroup(struct proto *prot, struct cgroup *cgrp,
struct cgroup_subsys *ss)
{
struct mem_cgroup *cg = mem_cgroup_from_cont(cgrp);
+ struct mem_cgroup *parent = parent_mem_cgroup(cg);
unsigned long limit;
struct net *net = current->nsproxy->net_ns;
@@ -481,12 +533,17 @@ int tcp_init_cgroup(struct proto *prot, struct cgroup *cgrp,
limit = nr_free_buffer_pages() / 8;
limit = max(limit, 128UL);
+ if (parent)
+ cg->tcp_max_memory = parent->tcp_max_memory;
+ else
+ cg->tcp_max_memory = limit * 2;
+
cg->tcp_prot_mem[0] = net->ipv4.sysctl_tcp_mem[0];
cg->tcp_prot_mem[1] = net->ipv4.sysctl_tcp_mem[1];
cg->tcp_prot_mem[2] = net->ipv4.sysctl_tcp_mem[2];
tcp_init_cgroup_fill(prot, cgrp, ss);
- return 0;
+ return cgroup_add_files(cgrp, ss, tcp_files, ARRAY_SIZE(tcp_files));
}
EXPORT_SYMBOL(tcp_init_cgroup);
@@ -499,6 +556,16 @@ void tcp_destroy_cgroup(struct proto *prot, struct cgroup *cgrp,
tcp_destroy_cgroup_fill(prot, cgrp, ss);
}
EXPORT_SYMBOL(tcp_destroy_cgroup);
+
+unsigned long tcp_max_memory(struct mem_cgroup *cg)
+{
+ return cg->tcp_max_memory;
+}
+
+void tcp_prot_mem(struct mem_cgroup *cg, long val, int idx)
+{
+ cg->tcp_prot_mem[idx] = val;
+}
#endif /* CONFIG_INET */
#endif /* CONFIG_CGROUP_MEM_RES_CTLR_KMEM */
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index bbd67ab..cdc35f6 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -14,6 +14,7 @@
#include <linux/init.h>
#include <linux/slab.h>
#include <linux/nsproxy.h>
+#include <linux/memcontrol.h>
#include <linux/swap.h>
#include <net/snmp.h>
#include <net/icmp.h>
@@ -182,6 +183,10 @@ static int ipv4_tcp_mem(ctl_table *ctl, int write,
int ret;
unsigned long vec[3];
struct net *net = current->nsproxy->net_ns;
+#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
+ int i;
+ struct mem_cgroup *cg;
+#endif
ctl_table tmp = {
.data = &vec,
@@ -198,6 +203,21 @@ static int ipv4_tcp_mem(ctl_table *ctl, int write,
if (ret)
return ret;
+#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
+ rcu_read_lock();
+ cg = mem_cgroup_from_task(current);
+ for (i = 0; i < 3; i++)
+ if (vec[i] > tcp_max_memory(cg)) {
+ rcu_read_unlock();
+ return -EINVAL;
+ }
+
+ tcp_prot_mem(cg, vec[0], 0);
+ tcp_prot_mem(cg, vec[1], 1);
+ tcp_prot_mem(cg, vec[2], 2);
+ rcu_read_unlock();
+#endif
+
net->ipv4.sysctl_tcp_mem[0] = vec[0];
net->ipv4.sysctl_tcp_mem[1] = vec[1];
net->ipv4.sysctl_tcp_mem[2] = vec[2];
--
1.7.6
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH v2 7/7] Display current tcp memory allocation in kmem cgroup
From: Glauber Costa @ 2011-09-15 1:46 UTC (permalink / raw)
To: linux-kernel
Cc: paul, lizf, kamezawa.hiroyu, ebiederm, davem, gthelen, netdev,
linux-mm, Glauber Costa
In-Reply-To: <1316051175-17780-1-git-send-email-glommer@parallels.com>
This patch introduces kmem.tcp_current_memory file, living in the
kmem_cgroup filesystem. It is a simple read-only file that displays the
amount of kernel memory currently consumed by the cgroup.
Signed-off-by: Glauber Costa <glommer@parallels.com>
CC: David S. Miller <davem@davemloft.net>
CC: Hiroyouki Kamezawa <kamezawa.hiroyu@jp.fujitsu.com>
CC: Eric W. Biederman <ebiederm@xmission.com>
---
Documentation/cgroups/memory.txt | 1 +
mm/memcontrol.c | 17 +++++++++++++++++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
index ce825ee..59d9416 100644
--- a/Documentation/cgroups/memory.txt
+++ b/Documentation/cgroups/memory.txt
@@ -79,6 +79,7 @@ Brief summary of control files.
memory.independent_kmem_limit # select whether or not kernel memory limits are
independent of user limits
memory.kmem.tcp.max_memory # set/show hard limit for tcp buf memory
+ memory.kmem.tcp.current_memory # show current tcp buf memory allocation
1. History
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index b48e517..dd0121f 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -482,12 +482,29 @@ static u64 tcp_read_maxmem(struct cgroup *cgrp, struct cftype *cft)
return ret;
}
+static u64 tcp_read_curmem(struct cgroup *cgrp, struct cftype *cft)
+{
+ struct mem_cgroup *sg = mem_cgroup_from_cont(cgrp);
+ u64 ret;
+
+ if (!cgroup_lock_live_group(cgrp))
+ return -ENODEV;
+ ret = atomic_long_read(&sg->tcp_memory_allocated);
+
+ cgroup_unlock();
+ return ret;
+}
+
static struct cftype tcp_files[] = {
{
.name = "kmem.tcp.max_memory",
.write_u64 = tcp_write_maxmem,
.read_u64 = tcp_read_maxmem,
},
+ {
+ .name = "kmem.tcp.current_memory",
+ .read_u64 = tcp_read_curmem,
+ },
};
/*
--
1.7.6
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: Draft manpage for recvmmsg
From: Michael Kerrisk @ 2011-09-15 4:15 UTC (permalink / raw)
To: Andi Kleen
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
acme-H+wXaHxf7aLQT0dZR+AlfA, Stephan Mueller, Anton Blanchard,
Linux API
In-Reply-To: <20101123101551.GA20431-u0/ZJuX+froe6aEkudXLsA@public.gmane.org>
[CC list expanded]
Hi Andi, (and Arnaldo)
As noted in an earlier mail, I still need to know what copyright and
license to attach to the page before I can release it.
See below for further comments.
On Tue, Nov 23, 2010 at 11:15 AM, Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> wrote:
>
> Here's a draft manpage for recvmmsg(2), which is one
> of the last undocumented syscalls currently.
> Please review and comment.
>
> -Andi
>
>
> .TH RECVMMSG 2 2010-11-23 "Linux" "Linux Programmer's Manual"
> .SH NAME
> recvmmsg \- receive multiple messages on a socket
> .SH SYNOPSIS
> .BI "#include <sys/socket.h>"
> .br
> .BI "int recvmmsg(int " fd ", struct mmsghdr *" mmsghdr \
> ", unsigned int " vlen ","
> .br
> .BI " unsigned int " flags ", struct timespec *" timeout ");"
> .SH DESCRIPTION
> The
> .B recvmmsg
> system call receives multiple messages in a socket.
> It acts similar to
> .B recvmsg(2),
> but allows to batch multiple receive operations into a single syscall.
> In addition it support an explicit timeout.
>
> .B fd
> is the file descriptor of the socket to receive data from.
> .B mmsghdr
> is a pointer to an array with length
> .B vlen
> of
> .I mmsghdr
> structures.
> .I struct mmsg
> is defined in
> .I sys/socket.h
> as:
> .in +4n
> .nf
> struct mmsghdr {
> struct msghdr msg_hdr; /* Message header */
> unsigned int msg_len; /* Number of received bytes for header */
> };
> .fi
> .in
> .PP
> .B msg_hdr
> is a struct
> .I msghdr
> as described in
> .I recvmsg(2).
> .B msg_len
> is the number of bytes returned for the message in the entry.
> This field has the same value as the return value of a single
> .I recvmsg(2)
> on the header.
>
> .B flags
> contains flags ored together. The flags are the same
> as documented for
> .I recvmsg(2).
> The additional
> .B MSG_WAITFORONE
> turns one
> .I MSG_DONTWAIT
> after the first message has been received.
>
> .B timeout
> points to a
> .I struct timespec
> (see
> .I clock_gettime(2)
> )
> defining a timeout for receiving, or
> .I NULL
> for no timeout. When the timeout expires
> .I recvmmsg
> returns.
> .SH RETURN VALUE
> .I recvmmsg
> returns the number of messages received in
> .I mmsghdr
> or
> -1
> when an error occurs. The
> .I msg_len
> members of
> .I mmsghdr
> are updated for each received message,
> in addition to other fields in the msg_hdr for each message,
> as described in
> .I recvmsg(2).
> .SH SEE ALSO
> .B recvmsg(2),
> .B sendmsg(2),
> .B socket(7),
> .B socket(2),
> .B clock_gettime(2)
> .SH VERSIONS
> The
> .I recvmmsg
> syscall was added with kernel 2.6.32.
> Support in glibc was added with 2.6.12.
> On earlier glibcs the function can be called
> manually using
> .I syscall(2).
I reworked a number of pieces of text, and added several other pieces.
Could you please take a look (for others interested: "man -l <file>")
at the version below and let me know of inaccuracies
Thanks,
Michael
.TH RECVMMSG 2 2011-09-09 "Linux" "Linux Programmer's Manual"
.SH NAME
recvmmsg \- receive multiple messages on a socket
.SH SYNOPSIS
.nf
.B "#define _GNU_SOURCE"
.BI "#include <sys/socket.h>"
.BI "int recvmmsg(int " sockfd ", struct mmsghdr *" msgvec \
", unsigned int " vlen ","
.br
.BI " unsigned int " flags ", struct timespec *" timeout ");"
.fi
.SH DESCRIPTION
The
.BR recvmmsg ()
system call is an extension of
.BR recvmsg (2)
that allows the caller to receive multiple messages from a socket
using a single system call.
(This has performance benefits for some applications.)
A further extension over
.BR recvmsg (2)
is support for a timeout on the receive operation.
The
.I sockfd
argument is the file descriptor of the socket to receive data from.
The
.I msgvec
argument is a pointer to an array of
.I mmsghdr
structures.
The size of this array is specified in
.IR vlen .
The
.I mmsghdr
structure is defined in
.I <sys/socket.h>
as:
.in +4n
.nf
struct mmsghdr {
struct msghdr msg_hdr; /* Message header */
unsigned int msg_len; /* Number of received bytes for header */
};
.fi
.in
.PP
The
.I msg_hdr
field is a
.I msghdr
structure, as described in
.BR recvmsg (2).
The
.I msg_len
field is the number of bytes returned for the message in the entry.
This field has the same value as the return value of a single
.BR recvmsg (2)
on the header.
The
.I flags
argument contains flags ORed together.
The flags are the same as documented for
.BR recvmsg (2),
with the following addition:
.TP
.B MSG_WAITFORONE
Turns on
.B MSG_DONTWAIT
after the first message has been received.
.PP
The
.I timeout
argument points to a
.I struct timespec
(see
.BR clock_gettime (2))
defining a timeout (seconds plus nanoseconds) for the receive operation.
If
.I timeout
is
.I NULL
then the operation blocks indefinitely.
A blocking
.BR recvmmsg ()
call blocks until
.I vlen
messages have been received
or until the timeout expires.
A nonblocking call reads as many messages as are available
(up to the limit specified by
.IR vlen )
and returns immediately.
On return from
.BR recvmmsg (),
successive elements of
.IR msgvec
are updated to contain information about each received message:
.I msg_len
contains the size of the received message;
the subfields of
.I msg_hdr
are updated as described in
.BR recvmsg (2).
The return value of the call indicates the number of elements of
.I msgvec
that have been updated.
.SH RETURN VALUE
On success,
.BR recvmmsg ()
returns the number of messages received in
.IR msgvec ;
on error, \-1 is returned, and
.I errno
is set to indicate the error.
.SH ERRORS
Errors are as for
.BR recvmsg (2).
In addition, the following error can occur:
.TP
.B EINVAL
.I timeout
is invalid.
.SH VERSIONS
The
.BR recvmmsg ()
system call was added in Linux 2.6.32.
Support in glibc was added in version 2.12.
.SH CONFORMING TO
.BR recvmmsg ()
is Linux-specific.
.SH SEE ALSO
.BR clock_gettime (2),
.BR recvmsg (2),
.BR sendmmsg (2),
.BR sendmsg (2),
.BR socket (2),
.BR socket (7)
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
^ permalink raw reply
* Re: [PATCH 2/3] netdev/of/phy: Add MDIO bus multiplexer support.
From: David Daney @ 2011-09-15 4:16 UTC (permalink / raw)
To: Grant Likely
Cc: David Daney, David Daney, linux-mips, linux-kernel,
David S. Miller, netdev, devicetree-discuss, ralf
In-Reply-To: <CACxGe6tA6D9JVf0_K-JAGnKcQmDmD=1ytqqYb6or-KjP9uZNxg@mail.gmail.com>
On 09/14/2011 05:51 PM, Grant Likely wrote:
>
>
> On Aug 31, 2011 2:01 PM, "David Daney" <david.daney@cavium.com
> <mailto:david.daney@cavium.com>> wrote:
> >
> > This patch adds a somewhat generic framework for MDIO bus
> > multiplexers. It is modeled on the I2C multiplexer.
> >
>
[...]
>
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/mdio-mux.txt
> > @@ -0,0 +1,132 @@
> > +Common MDIO bus multiplexer/switch properties.
> > +
> > +An MDIO bus multiplexer/switch will have several child busses that are
> > +numbered uniquely in a device dependent manner. The nodes for an MDIO
> > +bus multiplexer/switch will have one child node for each child bus.
> > +
> > +Required properties:
> > +- parent-bus : phandle to the parent MDIO bus.
>
> As discussed, I like mdio-parent-bus.
>
> > +
> > +Optional properties:
> > +- Other properties specific to the multiplexer/switch hardware.
> > +
> > +Required properties for child nodes:
> > +- #address-cells = <1>;
> > +- #size-cells = <0>;
> > +- cell-index : The sub-bus number.
>
> Use reg, not cell-index. That is what it is there for. And add the
> appropriate #address/size-cells in the parent.
>
> I've not reviewed the implementation, but with the changes. I'm okay
> with the binding.
>
Thanks for the prompt reply Grant.
I will rework this with the binding changes and send a new version soon.
David Daney
^ permalink raw reply
* sendmmsg(2) draft man pages
From: Michael Kerrisk @ 2011-09-15 4:16 UTC (permalink / raw)
To: Anton Blanchard
Cc: linux-man, Andi Kleen, Stephan Mueller, netdev, Linux API,
Michael Kerrisk
Hello Anton,
Stephan Mueller made an initial shot at a manual page for the
sendmmsg() syscall that you recently added to the kernel. This
inspired me to come up with a more complete version, which I'd like to
get reviewed before including in man-pages. Could you take a look
("man -l <file>") at the version below and let me know any errors or
omissions.
Thanks
Michael Kerrisk
.\" Copyright (c) 2011 by Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
.\" with some material from a draft by
.\" Stephan Mueller <stephan.mueller-fwYZOkdEjagAvxtiuMwx3w@public.gmane.org>
.\" in turn based on Andi Kleen's recvmmsg.2 page.
.\"
.\" Permission is granted to make and distribute verbatim copies of this
.\" manual provided the copyright notice and this permission notice are
.\" preserved on all copies.
.\"
.\" Permission is granted to copy and distribute modified versions of this
.\" manual under the conditions for verbatim copying, provided that the
.\" entire resulting derived work is distributed under the terms of a
.\" permission notice identical to this one.
.\"
.\" Since the Linux kernel and libraries are constantly changing, this
.\" manual page may be incorrect or out-of-date. The author(s) assume no
.\" responsibility for errors or omissions, or for damages resulting from
.\" the use of the information contained herein. The author(s) may not
.\" have taken the same level of care in the production of this manual,
.\" which is licensed free of charge, as they might when working
.\" professionally.
.\"
.\" Formatted or processed versions of this manual, if unaccompanied by
.\" the source, must acknowledge the copyright and authors of this work.
.\"
.TH SENDMMSG 2 2011-09-09 "Linux" "Linux Programmer's Manual"
.SH NAME
sendmmsg \- send multiple messages on a socket
.SH SYNOPSIS
.nf
.B "#define _GNU_SOURCE"
.BI "#include <sys/socket.h>"
.BI "int sendmmsg(int " sockfd ", struct mmsghdr *" msgvec \
", unsigned int " vlen ","
.BI " unsigned int " flags ");"
.fi
.SH DESCRIPTION
The
.BR sendmmsg ()
system call is an extension of
.BR sendmsg (2)
that allows the caller to transmit multiple messages on a socket
using a single system call.
(This has performance benefits for some applications.)
.\" See commit 228e548e602061b08ee8e8966f567c12aa079682
The
.I sockfd
argument is the file descriptor of the socket
on which data is to be transmitted.
The
.I msgvec
argument is a pointer to an array of
.I mmsghdr
structures.
The size of this array is specified in
.IR vlen .
The
.I mmsghdr
structure is defined in
.I <sys/socket.h>
as:
.in +4n
.nf
struct mmsghdr {
struct msghdr msg_hdr; /* Message header */
unsigned int msg_len; /* Number of bytes transmitted */
};
.fi
.in
.PP
The
.I msg_hdr
field is a
.I msghdr
structure, as described in
.BR sendmsg (2).
The
.I msg_len
field is used to return the number of bytes sent from the message in
.IR msg_hdr
(i.e., the same as the return value from a single
.BR sendmsg (2)
call).
The
.I flags
argument contains flags ORed together.
The flags are the same as for
.BR sendmsg (2).
A blocking
.BR sendmmsg ()
call blocks until
.I vlen
messages have been sent.
A nonblocking call sends as many messages as possible
(up to the limit specified by
.IR vlen )
and returns immediately.
On return from
.BR sendmmsg (),
the
.I msg_len
fields of successive elements of
.IR msgvec
are updated to contain the number of bytes transmitted from the corresponding
.IR msg_hdr .
The return value of the call indicates the number of elements of
.I msgvec
that have been updated.
.SH RETURN VALUE
On success,
.BR sendmmsg ()
returns the number of messages sent from
.IR msgvec ;
if this is less than
.IR vlen ,
the caller can retry with a further
.BR sendmmsg ()
call to send the remaining messages.
On error, \-1 is returned, and
.I errno
is set to indicate the error.
.SH ERRORS
Errors are as for
.BR sendmsg (2).
An error is returned only if no datagrams could be sent.
.\" commit 728ffb86f10873aaf4abd26dde691ee40ae731fe
.\" ... only return an error if no datagrams could be sent.
.\" If less than the requested number of messages were sent, the application
.\" must retry starting at the first failed one and if the problem is
.\" persistent the error will be returned.
.\"
.\" This matches the behaviour of other syscalls like read/write - it
.\" is not an error if less than the requested number of elements are sent.
.SH VERSIONS
The
.BR sendmmsg ()
system call was added in Linux 3.0.
Support in glibc was added in version 2.14.
.SH CONFORMING TO
.BR sendmmsg ()
is Linux-specific.
.SH NOTES
The value specified in
.I vlen
is capped to
.B UIO_MAXIOV
(1024).
.\" commit 98382f419f32d2c12d021943b87dea555677144b
.\" net: Cap number of elements for sendmmsg
.\"
.\" To limit the amount of time we can spend in sendmmsg, cap the
.\" number of elements to UIO_MAXIOV (currently 1024).
.\"
.\" For error handling an application using sendmmsg needs to retry at
.\" the first unsent message, so capping is simpler and requires less
.\" application logic than returning EINVAL.
.SH SEE ALSO
.BR recvmmsg (2),
.BR sendmsg (2),
.BR socket (2),
.BR socket (7)
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
^ permalink raw reply
* Re: e1000e: NIC not working, power management issue?
From: Lucas Nussbaum @ 2011-09-15 4:48 UTC (permalink / raw)
To: John Ronciak; +Cc: Frederik Himpe, netdev, e1000-devel, linux-kernel
In-Reply-To: <CALWPMBEvwFbP-G+Ojfr_vM2riwG9vax3_3cQ1SzBR4OmdnHnsw@mail.gmail.com>
On 14/09/11 at 14:14 -0700, John Ronciak wrote:
> On Wed, Sep 14, 2011 at 1:31 PM, Frederik Himpe <fhimpe@telenet.be> wrote:
>
> >>
> >> dmesg:
> >> [ 6260.327320] e1000e: Intel(R) PRO/1000 Network Driver - 1.4.4-k
> >> [ 6260.327324] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
> >> [ 6260.327355] e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
> >> [ 6260.327366] e1000e 0000:00:19.0: setting latency timer to 64
> >> [ 6260.327490] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
> >> [ 6260.517813] e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:24:e8:a7:2c:42
> >> [ 6260.517824] e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
> >> [ 6260.518077] e1000e 0000:00:19.0: eth0: MAC: 7, PHY: 8, PBA No: 3002FF-0FF
> >> [ 6260.518102] e1000e 0000:00:19.0: PME# enabled
> >> [ 6260.556129] e1000e 0000:00:19.0: BAR 0: set to [mem 0xf6ae0000-0xf6afffff] (PCI address [0xf6ae0000-0xf6afffff])
> >> [ 6260.556139] e1000e 0000:00:19.0: BAR 1: set to [mem 0xf6adb000-0xf6adbfff] (PCI address [0xf6adb000-0xf6adbfff])
> >> [ 6260.556147] e1000e 0000:00:19.0: BAR 2: set to [io 0xefe0-0xefff] (PCI address [0xefe0-0xefff])
> >> [ 6260.556167] e1000e 0000:00:19.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
> >> [ 6260.556193] e1000e 0000:00:19.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100107)
> >> [ 6260.556253] e1000e 0000:00:19.0: PME# disabled
> >> [ 6260.645141] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
> >> [ 6260.700393] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
> >> [ 6260.702222] ADDRCONF(NETDEV_UP): eth0: link is not ready
> It doesn't have link. Without link nothing can happen on the wire.
> What are you expecting to happen here?
>
> Have the device get link first.
What do you mean by "get link" ?
A network cable is plugged in the ethernet port, but it doesn't seem to be
detected in Linux 3.0 (while everything works fine in 2.6.32).
Also, it seems that link is detected when the laptop first boots, until a "MAC
Wakeup cause - Link Status Change" message:
[ 1.189506] e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:24:e8:a7:2c:42
[ 1.189579] e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
[ 1.189664] e1000e 0000:00:19.0: eth0: MAC: 7, PHY: 8, PBA No: 3002FF-0FF
[ 30.636723] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 33.780901] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
[ 33.783944] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[...]
[ 6255.418398] e1000e 0000:00:19.0: eth0: MAC Wakeup cause - Link Status Change
Lucas
^ permalink raw reply
* malloc() and flushcache
From: liang peng @ 2011-09-15 5:27 UTC (permalink / raw)
To: david.daney
Cc: linux-mips, ralf, devicetree-discuss, grant.likely, linux-kernel,
netdev
[-- Attachment #1: Type: text/plain, Size: 95 bytes --]
Hi, I want to know how to flushcache to the memory allocated by malloc()?
anybody help?
thanks
[-- Attachment #2: Type: text/html, Size: 115 bytes --]
^ permalink raw reply
* [net-next] MII: fix Kconfig dependencies for MII
From: Jeff Kirsher @ 2011-09-15 7:23 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo
MII Kconfig option is apart of the core networking drivers and
by default NET_CORE is enabled so drivers selecting MII will
have MII enabled as well. It was found using the randconfig
option during testing, MII would be selected but NET_CORE
could be disabled. This caused a dependency error.
Resolved the dependency by selecting NET_CORE when MII is
selected.
Reported-by: Emil Tantilov <emil.s.tantilov@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
---
arch/cris/arch-v10/drivers/Kconfig | 1 +
arch/cris/arch-v32/drivers/Kconfig | 1 +
drivers/net/ethernet/3com/Kconfig | 1 +
drivers/net/ethernet/Kconfig | 4 ++++
drivers/net/ethernet/adaptec/Kconfig | 1 +
drivers/net/ethernet/adi/Kconfig | 1 +
drivers/net/ethernet/amd/Kconfig | 2 ++
drivers/net/ethernet/atheros/Kconfig | 4 ++++
drivers/net/ethernet/broadcom/Kconfig | 2 ++
drivers/net/ethernet/cadence/Kconfig | 1 +
drivers/net/ethernet/cirrus/Kconfig | 1 +
drivers/net/ethernet/davicom/Kconfig | 1 +
drivers/net/ethernet/dec/tulip/Kconfig | 1 +
drivers/net/ethernet/dlink/Kconfig | 1 +
drivers/net/ethernet/faraday/Kconfig | 1 +
drivers/net/ethernet/freescale/fs_enet/Kconfig | 1 +
drivers/net/ethernet/icplus/Kconfig | 1 +
drivers/net/ethernet/intel/Kconfig | 1 +
drivers/net/ethernet/micrel/Kconfig | 4 ++++
drivers/net/ethernet/nuvoton/Kconfig | 1 +
drivers/net/ethernet/oki-semi/pch_gbe/Kconfig | 1 +
drivers/net/ethernet/packetengines/Kconfig | 1 +
drivers/net/ethernet/rdc/Kconfig | 1 +
drivers/net/ethernet/realtek/Kconfig | 3 +++
drivers/net/ethernet/renesas/Kconfig | 1 +
drivers/net/ethernet/sgi/Kconfig | 1 +
drivers/net/ethernet/sis/Kconfig | 2 ++
drivers/net/ethernet/smsc/Kconfig | 5 +++++
drivers/net/ethernet/stmicro/stmmac/Kconfig | 1 +
drivers/net/ethernet/via/Kconfig | 2 ++
drivers/net/usb/Kconfig | 3 +++
31 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/arch/cris/arch-v10/drivers/Kconfig b/arch/cris/arch-v10/drivers/Kconfig
index 0d72217..32d9086 100644
--- a/arch/cris/arch-v10/drivers/Kconfig
+++ b/arch/cris/arch-v10/drivers/Kconfig
@@ -4,6 +4,7 @@ config ETRAX_ETHERNET
bool "Ethernet support"
depends on ETRAX_ARCH_V10
select NET_ETHERNET
+ select NET_CORE
select MII
help
This option enables the ETRAX 100LX built-in 10/100Mbit Ethernet
diff --git a/arch/cris/arch-v32/drivers/Kconfig b/arch/cris/arch-v32/drivers/Kconfig
index 41a2732..e47e9c3 100644
--- a/arch/cris/arch-v32/drivers/Kconfig
+++ b/arch/cris/arch-v32/drivers/Kconfig
@@ -4,6 +4,7 @@ config ETRAX_ETHERNET
bool "Ethernet support"
depends on ETRAX_ARCH_V32
select NET_ETHERNET
+ select NET_CORE
select MII
help
This option enables the ETRAX FS built-in 10/100Mbit Ethernet
diff --git a/drivers/net/ethernet/3com/Kconfig b/drivers/net/ethernet/3com/Kconfig
index a439cbd..a8bb30c 100644
--- a/drivers/net/ethernet/3com/Kconfig
+++ b/drivers/net/ethernet/3com/Kconfig
@@ -81,6 +81,7 @@ config PCMCIA_3C589
config VORTEX
tristate "3c590/3c900 series (592/595/597) \"Vortex/Boomerang\" support"
depends on (PCI || EISA)
+ select NET_CORE
select MII
---help---
This option enables driver support for a large number of 10Mbps and
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index 1f64747..6dff5a0 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -62,6 +62,7 @@ config JME
tristate "JMicron(R) PCI-Express Gigabit Ethernet support"
depends on PCI
select CRC32
+ select NET_CORE
select MII
---help---
This driver supports the PCI-Express gigabit ethernet adapters
@@ -102,6 +103,7 @@ config FEALNX
tristate "Myson MTD-8xx PCI Ethernet support"
depends on PCI
select CRC32
+ select NET_CORE
select MII
---help---
Say Y here to support the Myson MTD-800 family of PCI-based Ethernet
@@ -112,6 +114,7 @@ source "drivers/net/ethernet/8390/Kconfig"
config NET_NETX
tristate "NetX Ethernet support"
+ select NET_CORE
select MII
depends on ARCH_NETX
---help---
@@ -128,6 +131,7 @@ source "drivers/net/ethernet/oki-semi/Kconfig"
config ETHOC
tristate "OpenCores 10/100 Mbps Ethernet MAC support"
depends on HAS_IOMEM && HAS_DMA
+ select NET_CORE
select MII
select PHYLIB
select CRC32
diff --git a/drivers/net/ethernet/adaptec/Kconfig b/drivers/net/ethernet/adaptec/Kconfig
index 5c804bb..0bff571 100644
--- a/drivers/net/ethernet/adaptec/Kconfig
+++ b/drivers/net/ethernet/adaptec/Kconfig
@@ -22,6 +22,7 @@ config ADAPTEC_STARFIRE
tristate "Adaptec Starfire/DuraLAN support"
depends on PCI
select CRC32
+ select NET_CORE
select MII
---help---
Say Y here if you have an Adaptec Starfire (or DuraLAN) PCI network
diff --git a/drivers/net/ethernet/adi/Kconfig b/drivers/net/ethernet/adi/Kconfig
index 6de9851..49a30d3 100644
--- a/drivers/net/ethernet/adi/Kconfig
+++ b/drivers/net/ethernet/adi/Kconfig
@@ -23,6 +23,7 @@ config BFIN_MAC
tristate "Blackfin on-chip MAC support"
depends on (BF516 || BF518 || BF526 || BF527 || BF536 || BF537)
select CRC32
+ select NET_CORE
select MII
select PHYLIB
select BFIN_MAC_USE_L1 if DMA_UNCACHED_NONE
diff --git a/drivers/net/ethernet/amd/Kconfig b/drivers/net/ethernet/amd/Kconfig
index 8af1c93..238b537 100644
--- a/drivers/net/ethernet/amd/Kconfig
+++ b/drivers/net/ethernet/amd/Kconfig
@@ -34,6 +34,7 @@ config AMD8111_ETH
tristate "AMD 8111 (new PCI LANCE) support"
depends on PCI
select CRC32
+ select NET_CORE
select MII
---help---
If you have an AMD 8111-based PCI LANCE ethernet card,
@@ -59,6 +60,7 @@ config PCNET32
tristate "AMD PCnet32 PCI support"
depends on PCI
select CRC32
+ select NET_CORE
select MII
---help---
If you have a PCnet32 or PCnetPCI based network (Ethernet) card,
diff --git a/drivers/net/ethernet/atheros/Kconfig b/drivers/net/ethernet/atheros/Kconfig
index 26ab8ca..1ed886d 100644
--- a/drivers/net/ethernet/atheros/Kconfig
+++ b/drivers/net/ethernet/atheros/Kconfig
@@ -22,6 +22,7 @@ config ATL2
tristate "Atheros L2 Fast Ethernet support"
depends on PCI
select CRC32
+ select NET_CORE
select MII
---help---
This driver supports the Atheros L2 fast ethernet adapter.
@@ -33,6 +34,7 @@ config ATL1
tristate "Atheros/Attansic L1 Gigabit Ethernet support"
depends on PCI
select CRC32
+ select NET_CORE
select MII
---help---
This driver supports the Atheros/Attansic L1 gigabit ethernet
@@ -45,6 +47,7 @@ config ATL1E
tristate "Atheros L1E Gigabit Ethernet support (EXPERIMENTAL)"
depends on PCI && EXPERIMENTAL
select CRC32
+ select NET_CORE
select MII
---help---
This driver supports the Atheros L1E gigabit ethernet adapter.
@@ -56,6 +59,7 @@ config ATL1C
tristate "Atheros L1C Gigabit Ethernet support (EXPERIMENTAL)"
depends on PCI && EXPERIMENTAL
select CRC32
+ select NET_CORE
select MII
---help---
This driver supports the Atheros L1C gigabit ethernet adapter.
diff --git a/drivers/net/ethernet/broadcom/Kconfig b/drivers/net/ethernet/broadcom/Kconfig
index d82ad22..f15e72e 100644
--- a/drivers/net/ethernet/broadcom/Kconfig
+++ b/drivers/net/ethernet/broadcom/Kconfig
@@ -22,6 +22,7 @@ config B44
tristate "Broadcom 440x/47xx ethernet support"
depends on SSB_POSSIBLE && HAS_DMA
select SSB
+ select NET_CORE
select MII
---help---
If you have a network (Ethernet) controller of this type, say Y
@@ -53,6 +54,7 @@ config B44_PCI
config BCM63XX_ENET
tristate "Broadcom 63xx internal mac support"
depends on BCM63XX
+ select NET_CORE
select MII
select PHYLIB
help
diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
index c00e706..98849a1 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -25,6 +25,7 @@ if NET_ATMEL
config ARM_AT91_ETHER
tristate "AT91RM9200 Ethernet support"
depends on ARM && ARCH_AT91RM9200
+ select NET_CORE
select MII
---help---
If you wish to compile a kernel for the AT91RM9200 and enable
diff --git a/drivers/net/ethernet/cirrus/Kconfig b/drivers/net/ethernet/cirrus/Kconfig
index e0cacf6..e9386ef 100644
--- a/drivers/net/ethernet/cirrus/Kconfig
+++ b/drivers/net/ethernet/cirrus/Kconfig
@@ -21,6 +21,7 @@ if NET_VENDOR_CIRRUS
config EP93XX_ETH
tristate "EP93xx Ethernet support"
depends on ARM && ARCH_EP93XX
+ select NET_CORE
select MII
help
This is a driver for the ethernet hardware included in EP93xx CPUs.
diff --git a/drivers/net/ethernet/davicom/Kconfig b/drivers/net/ethernet/davicom/Kconfig
index 73c5d20..972b62b 100644
--- a/drivers/net/ethernet/davicom/Kconfig
+++ b/drivers/net/ethernet/davicom/Kconfig
@@ -6,6 +6,7 @@ config DM9000
tristate "DM9000 support"
depends on ARM || BLACKFIN || MIPS
select CRC32
+ select NET_CORE
select MII
---help---
Support for DM9000 chipset.
diff --git a/drivers/net/ethernet/dec/tulip/Kconfig b/drivers/net/ethernet/dec/tulip/Kconfig
index f6af772..1203be0 100644
--- a/drivers/net/ethernet/dec/tulip/Kconfig
+++ b/drivers/net/ethernet/dec/tulip/Kconfig
@@ -125,6 +125,7 @@ config WINBOND_840
tristate "Winbond W89c840 Ethernet support"
depends on PCI
select CRC32
+ select NET_CORE
select MII
---help---
This driver is for the Winbond W89c840 chip. It also works with
diff --git a/drivers/net/ethernet/dlink/Kconfig b/drivers/net/ethernet/dlink/Kconfig
index 84a28a6..b5afe21 100644
--- a/drivers/net/ethernet/dlink/Kconfig
+++ b/drivers/net/ethernet/dlink/Kconfig
@@ -66,6 +66,7 @@ config SUNDANCE
tristate "Sundance Alta support"
depends on PCI
select CRC32
+ select NET_CORE
select MII
---help---
This driver is for the Sundance "Alta" chip.
diff --git a/drivers/net/ethernet/faraday/Kconfig b/drivers/net/ethernet/faraday/Kconfig
index 5918c68..b8974b9 100644
--- a/drivers/net/ethernet/faraday/Kconfig
+++ b/drivers/net/ethernet/faraday/Kconfig
@@ -21,6 +21,7 @@ if NET_VENDOR_FARADAY
config FTMAC100
tristate "Faraday FTMAC100 10/100 Ethernet support"
depends on ARM
+ select NET_CORE
select MII
---help---
This driver supports the FTMAC100 10/100 Ethernet controller
diff --git a/drivers/net/ethernet/freescale/fs_enet/Kconfig b/drivers/net/ethernet/freescale/fs_enet/Kconfig
index be92229..268414d 100644
--- a/drivers/net/ethernet/freescale/fs_enet/Kconfig
+++ b/drivers/net/ethernet/freescale/fs_enet/Kconfig
@@ -1,6 +1,7 @@
config FS_ENET
tristate "Freescale Ethernet Driver"
depends on NET_VENDOR_FREESCALE && (CPM1 || CPM2 || PPC_MPC512x)
+ select NET_CORE
select MII
select PHYLIB
diff --git a/drivers/net/ethernet/icplus/Kconfig b/drivers/net/ethernet/icplus/Kconfig
index e888222..3aff81d 100644
--- a/drivers/net/ethernet/icplus/Kconfig
+++ b/drivers/net/ethernet/icplus/Kconfig
@@ -5,6 +5,7 @@
config IP1000
tristate "IP1000 Gigabit Ethernet support"
depends on PCI && EXPERIMENTAL
+ select NET_CORE
select MII
---help---
This driver supports IP1000 gigabit Ethernet cards.
diff --git a/drivers/net/ethernet/intel/Kconfig b/drivers/net/ethernet/intel/Kconfig
index 4a98e83..61029dc 100644
--- a/drivers/net/ethernet/intel/Kconfig
+++ b/drivers/net/ethernet/intel/Kconfig
@@ -21,6 +21,7 @@ if NET_VENDOR_INTEL
config E100
tristate "Intel(R) PRO/100+ support"
depends on PCI
+ select NET_CORE
select MII
---help---
This driver supports Intel(R) PRO/100 family of adapters.
diff --git a/drivers/net/ethernet/micrel/Kconfig b/drivers/net/ethernet/micrel/Kconfig
index bd090db..d10c2e1 100644
--- a/drivers/net/ethernet/micrel/Kconfig
+++ b/drivers/net/ethernet/micrel/Kconfig
@@ -22,6 +22,7 @@ if NET_VENDOR_MICREL
config ARM_KS8695_ETHER
tristate "KS8695 Ethernet support"
depends on ARM && ARCH_KS8695
+ select NET_CORE
select MII
---help---
If you wish to compile a kernel for the KS8695 and want to
@@ -38,6 +39,7 @@ config KS8842
config KS8851
tristate "Micrel KS8851 SPI"
depends on SPI
+ select NET_CORE
select MII
select CRC32
---help---
@@ -46,6 +48,7 @@ config KS8851
config KS8851_MLL
tristate "Micrel KS8851 MLL"
depends on HAS_IOMEM
+ select NET_CORE
select MII
---help---
This platform driver is for Micrel KS8851 Address/data bus
@@ -54,6 +57,7 @@ config KS8851_MLL
config KSZ884X_PCI
tristate "Micrel KSZ8841/2 PCI"
depends on PCI
+ select NET_CORE
select MII
select CRC32
---help---
diff --git a/drivers/net/ethernet/nuvoton/Kconfig b/drivers/net/ethernet/nuvoton/Kconfig
index 01182b5..334c171 100644
--- a/drivers/net/ethernet/nuvoton/Kconfig
+++ b/drivers/net/ethernet/nuvoton/Kconfig
@@ -22,6 +22,7 @@ config W90P910_ETH
tristate "Nuvoton w90p910 Ethernet support"
depends on ARM && ARCH_W90X900
select PHYLIB
+ select NET_CORE
select MII
---help---
Say Y here if you want to use built-in Ethernet ports
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig b/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig
index c85709d..7efa624 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig
@@ -5,6 +5,7 @@
config PCH_GBE
tristate "OKI SEMICONDUCTOR ML7223 IOH GbE (Intel EG20T PCH)"
depends on PCI
+ select NET_CORE
select MII
---help---
This is a gigabit ethernet driver for EG20T PCH.
diff --git a/drivers/net/ethernet/packetengines/Kconfig b/drivers/net/ethernet/packetengines/Kconfig
index 4add1db..b97132d 100644
--- a/drivers/net/ethernet/packetengines/Kconfig
+++ b/drivers/net/ethernet/packetengines/Kconfig
@@ -20,6 +20,7 @@ if NET_PACKET_ENGINE
config HAMACHI
tristate "Packet Engines Hamachi GNIC-II support"
depends on PCI
+ select NET_CORE
select MII
---help---
If you have a Gigabit Ethernet card of this type, say Y and read
diff --git a/drivers/net/ethernet/rdc/Kconfig b/drivers/net/ethernet/rdc/Kconfig
index 2055f7e..c8ba4b3 100644
--- a/drivers/net/ethernet/rdc/Kconfig
+++ b/drivers/net/ethernet/rdc/Kconfig
@@ -22,6 +22,7 @@ config R6040
tristate "RDC R6040 Fast Ethernet Adapter support"
depends on PCI
select CRC32
+ select NET_CORE
select MII
select PHYLIB
---help---
diff --git a/drivers/net/ethernet/realtek/Kconfig b/drivers/net/ethernet/realtek/Kconfig
index d8df67a..84083ec 100644
--- a/drivers/net/ethernet/realtek/Kconfig
+++ b/drivers/net/ethernet/realtek/Kconfig
@@ -37,6 +37,7 @@ config 8139CP
tristate "RealTek RTL-8139 C+ PCI Fast Ethernet Adapter support (EXPERIMENTAL)"
depends on PCI && EXPERIMENTAL
select CRC32
+ select NET_CORE
select MII
---help---
This is a driver for the Fast Ethernet PCI network cards based on
@@ -51,6 +52,7 @@ config 8139TOO
tristate "RealTek RTL-8129/8130/8139 PCI Fast Ethernet Adapter support"
depends on PCI
select CRC32
+ select NET_CORE
select MII
---help---
This is a driver for the Fast Ethernet PCI network cards based on
@@ -105,6 +107,7 @@ config R8169
depends on PCI
select FW_LOADER
select CRC32
+ select NET_CORE
select MII
---help---
Say Y here if you have a Realtek 8169 PCI Gigabit Ethernet adapter.
diff --git a/drivers/net/ethernet/renesas/Kconfig b/drivers/net/ethernet/renesas/Kconfig
index f57ae23..9755b49 100644
--- a/drivers/net/ethernet/renesas/Kconfig
+++ b/drivers/net/ethernet/renesas/Kconfig
@@ -9,6 +9,7 @@ config SH_ETH
CPU_SUBTYPE_SH7763 || CPU_SUBTYPE_SH7619 || \
CPU_SUBTYPE_SH7724 || CPU_SUBTYPE_SH7757)
select CRC32
+ select NET_CORE
select MII
select MDIO_BITBANG
select PHYLIB
diff --git a/drivers/net/ethernet/sgi/Kconfig b/drivers/net/ethernet/sgi/Kconfig
index e832f46..c1c4bb8 100644
--- a/drivers/net/ethernet/sgi/Kconfig
+++ b/drivers/net/ethernet/sgi/Kconfig
@@ -22,6 +22,7 @@ config SGI_IOC3_ETH
bool "SGI IOC3 Ethernet"
depends on PCI && SGI_IP27
select CRC32
+ select NET_CORE
select MII
---help---
If you have a network (Ethernet) card of this type, say Y and read
diff --git a/drivers/net/ethernet/sis/Kconfig b/drivers/net/ethernet/sis/Kconfig
index 68d052b..f1135cc 100644
--- a/drivers/net/ethernet/sis/Kconfig
+++ b/drivers/net/ethernet/sis/Kconfig
@@ -22,6 +22,7 @@ config SIS900
tristate "SiS 900/7016 PCI Fast Ethernet Adapter support"
depends on PCI
select CRC32
+ select NET_CORE
select MII
---help---
This is a driver for the Fast Ethernet PCI network cards based on
@@ -38,6 +39,7 @@ config SIS190
tristate "SiS190/SiS191 gigabit ethernet support"
depends on PCI
select CRC32
+ select NET_CORE
select MII
---help---
Say Y here if you have a SiS 190 PCI Fast Ethernet adapter or
diff --git a/drivers/net/ethernet/smsc/Kconfig b/drivers/net/ethernet/smsc/Kconfig
index f961928..1854c88 100644
--- a/drivers/net/ethernet/smsc/Kconfig
+++ b/drivers/net/ethernet/smsc/Kconfig
@@ -37,6 +37,7 @@ config SMC9194
config SMC91X
tristate "SMC 91C9x/91C1xxx support"
select CRC32
+ select NET_CORE
select MII
depends on (ARM || M32R || SUPERH || MIPS || BLACKFIN || \
MN10300 || COLDFIRE)
@@ -56,6 +57,7 @@ config PCMCIA_SMC91C92
tristate "SMC 91Cxx PCMCIA support"
depends on PCMCIA
select CRC32
+ select NET_CORE
select MII
---help---
Say Y here if you intend to attach an SMC 91Cxx compatible PCMCIA
@@ -68,6 +70,7 @@ config EPIC100
tristate "SMC EtherPower II"
depends on PCI
select CRC32
+ select NET_CORE
select MII
---help---
This driver is for the SMC EtherPower II 9432 PCI Ethernet NIC,
@@ -78,6 +81,7 @@ config EPIC100
config SMC911X
tristate "SMSC LAN911[5678] support"
select CRC32
+ select NET_CORE
select MII
depends on (ARM || SUPERH || MN10300)
---help---
@@ -95,6 +99,7 @@ config SMSC911X
tristate "SMSC LAN911x/LAN921x families embedded ethernet support"
depends on (ARM || SUPERH || BLACKFIN || MIPS || MN10300)
select CRC32
+ select NET_CORE
select MII
select PHYLIB
---help---
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index cda61e3..2346ba0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -1,6 +1,7 @@
config STMMAC_ETH
tristate "STMicroelectronics 10/100/1000 Ethernet driver"
depends on HAS_IOMEM
+ select NET_CORE
select MII
select PHYLIB
select CRC32
diff --git a/drivers/net/ethernet/via/Kconfig b/drivers/net/ethernet/via/Kconfig
index e5d82a5..68a9ba6 100644
--- a/drivers/net/ethernet/via/Kconfig
+++ b/drivers/net/ethernet/via/Kconfig
@@ -22,6 +22,7 @@ config VIA_RHINE
tristate "VIA Rhine support"
depends on PCI
select CRC32
+ select NET_CORE
select MII
---help---
If you have a VIA "Rhine" based network card (Rhine-I (VT86C100A),
@@ -47,6 +48,7 @@ config VIA_VELOCITY
depends on PCI
select CRC32
select CRC_CCITT
+ select NET_CORE
select MII
---help---
If you have a VIA "Velocity" based network card say Y here.
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 84d4608..2335761 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -68,6 +68,7 @@ config USB_KAWETH
config USB_PEGASUS
tristate "USB Pegasus/Pegasus-II based ethernet device support"
+ select NET_CORE
select MII
---help---
Say Y here if you know you have Pegasus or Pegasus-II based adapter.
@@ -84,6 +85,7 @@ config USB_PEGASUS
config USB_RTL8150
tristate "USB RTL8150 based ethernet device support (EXPERIMENTAL)"
depends on EXPERIMENTAL
+ select NET_CORE
select MII
help
Say Y here if you have RTL8150 based usb-ethernet adapter.
@@ -95,6 +97,7 @@ config USB_RTL8150
config USB_USBNET
tristate "Multi-purpose USB Networking Framework"
+ select NET_CORE
select MII
---help---
This driver supports several kinds of network links over USB,
--
1.7.6
^ permalink raw reply related
* Re: r8169 hard-freezes the system on big network loads
From: Michael Brade @ 2011-09-15 10:26 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, nic_swsd, Hayes
In-Reply-To: <20110915000332.GA13821@electric-eye.fr.zoreil.com>
On Thursday 15 September 2011 02:03:32 Francois Romieu wrote:
> Michael Brade <brade@informatik.uni-muenchen.de> :
> [...]
>
> > ok, good news: I did not experience any freeze anymore even though I
> > transfered 60 GB. And I applied both of your patches and
> >
> > - if (status & RxFOVF) {
> > - rtl8169_schedule_work(dev,
> > rtl8169_reset_task); -
> > dev->stats.rx_fifo_errors++;
> > - }
>
> It should not be necessary to remove this part : the status mask is
> supposed to take care of it. One of my patches is wrong if this part
> needs to go away.
ok, I only removed it because you told me so the first time.
> [...]
>
> > so yes but what do you mean with "no real network traffic"? I still get
> > 100 MB/s.
>
> 100 MB/s as 100 Mbyte/s on a gigabit link or 100 Mbit/s on a {gigabit /
> fast} ethernet link ?
100 Mbytes on a gigabit link, so almost 100% usage (with ups and downs, of course; maybe
between 90 MB/s and 112 MB/s).
thanks,
Michael
^ permalink raw reply
* Soft vs. hard MTU / 802.3as
From: David Lamparter @ 2011-09-15 10:29 UTC (permalink / raw)
To: netdev
Hi,
I've been looking at implementing 802.1ad S-VLANs (I posted a patch but
lacked resources to work on it after my laptop died) and I'm running
into problems with the way the MTU is treated currently.
Basically, the code has no way to ascertain hardware maximum frame size
limits for stacked VLAN tags. (Which becomes even more important for
802.1ah, having 18 bytes of extra header...)
So, unless I'm overlooking something here, I'd suggest introducing two
new fields into struct net_device:
unsigned int hard_mtu;
unsigned short(?) extra_vlans;
The first one would be the hardware frame size limit on TX/RX. (These
shouldn't differ, if they do it needs to be the minimum).
The second one is a bit non-intuitive (maybe I'm over-thinking this?)
I'm expecting devices that support "1518 bytes plus 1 vlan tag". Those
devices cannot tx/rx 1522 byte frames, but if it is 1518 bytes plus a
1Q tag that's ok. So, basically, this field would be 0 for devices
that have a vlan-agnostic size limit, and 1 for silicon that has
"speshul" vlans. (VLAN accel is independent of this!)
So, if you add a 802.1Q vlan device, it works like this:
self->hard_mtu = parent->hard_mtu;
self->extra_vlans = parent->extra_vlans;
if (parent->extra_vlans)
self->extra_vlans--;
else
self->hard_mtu -= 4;
802.1ad/ah devices would be simpler:
self->hard_mtu = parent->hard_mtu - 4;
self->extra_vlans = 0;
(for 802.1ah the value is 16+6 bytes instead of 4)
Introducing these fields might also allow us to clean up MTU checks in
general; the device could be mostly agnostic of whatever is set above it
(though maybe we want to propagate the value for dropping oversized
frames early?).
The mtu field cannot be used for all of those things since layer 2 and
layer 3 MTU need to be distinguished. 802.3as calls for a 2000 byte MTU
but rather clearly says that only 1500 of it is for the higher level
protocol to use. The mtu knob needs to control IP's and IPv6's packet
sizes independently of what's transmitted by some vlan stack.
Comments?
(will come up with some code if i don't get overwhelming negative)
-David
P.S.: quick IEEE number cheat-sheet:
802.1Q - regular VLANs, protocol 0x8100, 4 byte total overhead
802.1ad - S(ervice)-VLANs, protocol 0x88a8, 4 byte total ovh.
802.1ah - MAC-in-MAC, protocol 0x88e7, 18 byte ovh.
802.3ac - frame size update for 802.3 to 1522 for one .1Q tag
802.3as - frame size update for 802.3 to 2000 for random stuff
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Roopa Prabhu @ 2011-09-15 13:46 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Sridhar Samudrala, netdev, dragos.tatulea, arnd, dwang2, benve,
kaber, davem, eric.dumazet, mchan, kvm
In-Reply-To: <CA93894D.33EF8%roprabhu@cisco.com>
The netlink patch is still in the works. I will post the patches after I
clean it up a bit and also accommodate or find answers to most questions
discussed for non-passthru case. Thought I will post the netlink interface
here to see if anyone has any early comments. I have a
rtnl_link_ops->set_rx_filter defined.
[IFLA_RX_FILTER] = {
[IFLA_ADDRESS_FILTER] = {
[IFLA_ADDRESS_FILTER_FLAGS]
[IFLA_ADDRESS_LIST] = {
[IFLA_ADDRESS_LIST_ENTRY]
}
}
[IFLA_VLAN_FILTER] = {
[IFLA_VLAN_LIST] = {
[IFLA_VLAN]
}
}
}
Some open questions:
- The VLAN filter above shows a VLAN list. It could also be a bitmap or
the interface could provide both a bitmap and VLAN list for more flexibility
. Like the below
[IFLA_RX_FILTER] = {
[IFLA_ADDRESS_FILTER] = {
[IFLA_ADDRESS_FILTER_FLAGS]
[IFLA_ADDRESS_LIST] = {
[IFLA_ADDRESS_LIST_ENTRY]
}
}
[IFLA_VLAN_FILTER] = {
[IFLA_VLAN_BITMAP]
[IFLA_VLAN_LIST] = {
[IFLA_VLAN]
}
}
}
- Do you see any advantage in keeping Unicast and multicast address list
separate ? Something like the below :
[IFLA_RX_FILTER] = {
[IFLA_ADDRESS_FILTER_FLAGS]
[IFLA_UC_ADDRESS_FILTER] = {
[IFLA_ADDRESS_LIST] = {
[IFLA_ADDRESS_LIST_ENTRY]
}
}
[IFLA_MC_ADDRESS_FILTER] = {
[IFLA_ADDRESS_LIST] = {
[IFLA_ADDRESS_LIST_ENTRY]
}
}
[IFLA_VLAN_FILTER] = {
[IFLA_VLAN_LIST] = {
[IFLA_VLAN]
}
}
}
- Is there any need to keep address and vlan filters separate. And have
two rtnl_link_ops, set_rx_address_filter, set_rx_vlan_filter ?. I don't see
one .
[IFLA_RX_ADDRESS_FILTER] = {
[IFLA_ADDRESS_FILTER_FLAGS]
[IFLA_ADDRESS_LIST] = {
[IFLA_ADDRESS_LIST_ENTRY]
}
}
[IFLA_RX_VLAN_FILTER] = {
[IFLA_VLAN_LIST] = {
[IFLA_VLAN]
}
}
Thanks,
Roopa
On 9/12/11 10:02 AM, "Roopa Prabhu" <roprabhu@cisco.com> wrote:
>
>
>
> On 9/11/11 12:03 PM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
>> On Sun, Sep 11, 2011 at 06:18:01AM -0700, Roopa Prabhu wrote:
>>>
>>>
>>>
>>> On 9/11/11 2:44 AM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>>>
>>>>
>>>> Yes, but what I mean is, if the size of the single filter table
>>>> is limited, we need to decide how many addresses is
>>>> each guest allowed. If we let one guest ask for
>>>> as many as it wants, it can lock others out.
>>>
>>> Yes true. In these cases ie when the number of unicast addresses being
>>> registered is more than it can handle, The VF driver will put the VF in
>>> promiscuous mode (Or at least its supposed to do. I think all drivers do
>>> that).
>>>
>>>
>>> Thanks,
>>> Roopa
>>
>> Right, so that works at least but likely performs worse
>> than a hardware filter. So we better allocate it in
>> some fair way, as a minimum. Maybe a way for
>> the admin to control that allocation is useful.
>
> Yes I think we will have to do something like that. There is a maximum that hw
> can support. Might need to consider that too. But there is no interface to get
> that today. I think the virtualization case gets a little trickier. Virtio-net
> allows upto 64 unicast addresses. But the lowerdev may allow only upto say 10
> unicast addresses (I think intel supports 10 unicast addresses on the VF). Am
> not sure if there is a good way to notify the guest of blocked addresses.
> Maybe putting the lower dev in promiscuous mode could be a policy decision too
> in this case.
>
> One other thing, I had indicated that I will look up details on opening my
> patch for non-passthru to enable hw filtering (without adding filtering
> support in macvlan right away. Ie phase1). Turns out in current code in
> macvlan_handle_frame, for non-passthru case, it does not fwd unicast pkts
> destined to macs other than the ones in macvlan hash. So a filter or hash
> lookup there for additional unicast addresses needs to be definitely added for
> non-passthru.
>
> Thanks,
> Roopa
>
>
>
^ permalink raw reply
* Re: sendmmsg(2) draft man pages
From: Stephan Mueller @ 2011-09-15 15:04 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w
Cc: Anton Blanchard, linux-man, Andi Kleen, netdev, Linux API,
Michael Kerrisk
In-Reply-To: <CAKgNAkhQu7LdGDh5=CMpTwsnmS03QRqojBpwSpAcFO55WdYWqw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 15.09.2011 06:16:22, +0200, Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
Hi Michael,
> Hello Anton,
>
> Stephan Mueller made an initial shot at a manual page for the
> sendmmsg() syscall that you recently added to the kernel. This
> inspired me to come up with a more complete version, which I'd like to
> get reviewed before including in man-pages. Could you take a look
> ("man -l <file>") at the version below and let me know any errors or
> omissions.
Thank you very much for the update. I have no comments.
Thanks
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-man" 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
* URGENT
From: HARRIS ROBIN ESQ @ 2011-09-15 15:08 UTC (permalink / raw)
This is to notify you once again as my previous letter were returned undelivered that late Theo Albrecht made you a beneficiary to his WILL. He left the sum of Thirty Million, One Hundred Thousand Dollars (USD$30,100.000.00) to you in the Codicil and last testament to his WILL.
Please if I reach you as I am hopeful, endeavor to get back to me as soon as possible to enable me conclude my job.
You are advice to contact me with my below Email: harrisrobinschamber@live.co.uk
I await your prompt response.
Yours in Service,
BARRISTER HARRIS ROBIN ESQ
^ permalink raw reply
* Re: [PATCH net-next-2.6] e1000: don't enable dma receives until after dma address has been setup
From: Jesse Brandeburg @ 2011-09-15 17:21 UTC (permalink / raw)
To: Dean Nelson
Cc: Michael S. Tsirkin, e1000-devel, netdev@vger.kernel.org,
jesse.brandeburg, Andy Gospodarek
In-Reply-To: <20110915003138.4279.19020.email-sent-by-dnelson@localhost6.localdomain6>
On Wed, 14 Sep 2011 17:31:38 -0700
Dean Nelson <dnelson@redhat.com> wrote:
> Doing an 'ifconfig ethN down' followed by an 'ifconfig ethN up' on a
> qemu-kvm guest system configured with two e1000 NICs can result in an
> 'unable to handle kernel paging request at 0000000100000000' or 'bad
> page map in process ...' or something similar.
<snip>
> The corruption appears to result from the following...
>
> . An 'ifconfig ethN down' gets us into e1000_close(), which through
> a number of subfunctions results in:
> 1. E1000_RCTL_EN being cleared in RCTL register. [e1000_down()]
> 2. dma_free_coherent() being called. [e1000_free_rx_resources()]
>
> . An 'ifconfig ethN up' gets us into e1000_open(), which through a
> number of subfunctions results in:
> 1. dma_alloc_coherent() being called.
> [e1000_setup_rx_resources()] 2. E1000_RCTL_EN being set in RCTL
> register. [e1000_setup_rctl()] 3. E1000_RCTL_EN being cleared in
> RCTL register. [e1000_configure_rx()] 4. RDLEN, RDBAH and RDBAL
> registers being set to reflect the dma page allocated in step 1.
> [e1000_configure_rx()] 5. E1000_RCTL_EN being set in RCTL register.
> [e1000_configure_rx()]
>
> During the 'ifconfig ethN up' there is a window opened, starting in
> step 2 where the receives are enabled up until they are disabled in
> step 3, in which the address of the receive descriptor dma page known
> by the NIC is still the previous one which was freed during the
> 'ifconfig ethN down'. If this memory has been reallocated for some
> other use and the NIC feels so inclined, it will write to that former
> dma page with predictably unpleasant results.
>
> I realize that in the guest, we're dealing with an e1000 NIC that is
> software emulated by qemu-kvm. The problem doesn't appear to occur on
> bare-metal. Andy suspects that this is because in the emulator
> link-up is essentially instant and traffic can start flowing
> immediately. Whereas on bare-metal, link-up usually seems to take at
> least a few milliseconds. And this might be enough to prevent traffic
> from flowing into the device inside the window where E1000_RCTL_EN is
> set.
nice analysis dean, yes, we shouldn't enable rx before we have the
hardware all ready.
You didn't mention however that the hardware is reset in e1000_down,
which will clear the RDBAL/RDBAH in real hardware.
>
> So perhaps a modification needs to be made to the qemu-kvm e1000 NIC
> emulator to delay the link-up. But in defense of the emulator, it
> seems like a bad idea to enable dma operations before the address of
> the memory to be involved has been made known.
the hardware reset code in kvm should also reset to default many
registers (almost all of them in fact) which may also end up solving
the problem.
>
> The following patch no longer enables receives in e1000_setup_rctl()
> but leaves them however they were. It only enables receives in
> e1000_configure_rx(), and only after the dma address has been made
> known to the hardware.
I still like your patch better as it is more correct. We could also
correct the kvm virtual hardware driver.
> There are two places where e1000_setup_rctl() gets called. The one in
> e1000_configure() is followed immediately by a call to
> e1000_configure_rx(), so there's really no change functionally
> (except for the removal of the problem window. The other is in
> __e1000_shutdown() and is not followed by a call to
> e1000_configure_rx(), so there is a change functionally. But
> consider...
>
> . An 'ifconfig ethN down' (just as described above).
>
> . A 'suspend' of the system, which (I'm assuming) will find its way
> into e1000_suspend() which calls __e1000_shutdown() resulting in:
> 1. E1000_RCTL_EN being set in RCTL register.
> [e1000_setup_rctl()]
>
> And again we've re-opened the problem window for some unknown amount
> of time.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> Signed-off-by: Dean Nelson <dnelson@redhat.com>
>
> ---
> The patch below is Andy's version of a patch I came up with to
> address this problem. I liked his version better. Functionally there
> was no difference between the two.
>
> Running my version of the patch, the reproducer (see script below)
> ran for 5 days without issue before I stopped it. Without the patch,
> former dma pages were corrupted in a very short timeframe and fairly
> frequently (relatively speaking). Note that I'm also running with a
> debug patch that after step 5 has completed (mentioned above under an
> 'ifconfig ethN up'...), the previous dma page is scanned to see if it
> had been 'corrupted'. So I found a higher percentage of occurrences
> then one would find if one waits for a kernel BUG.
>
> The reproducer for this problem is:
> cat > reproducer.sh <<EOF
> #!/bin/bash
> typeset -i i=0
> echo eth1:down
> ifconfig eth1 down
> sleep 2
> while :; do
> i=$i+1
> ifconfig eth0 down& ifconfig eth1 up&
> echo "$i | eth0:down eth1:up"
> wait
> sleep 2
> ifconfig eth0 up& ifconfig eth1 down&
> echo "$i | eth0:up eth1:down"
> wait
> sleep 2
> done
> EOF
>
> The e1000e looks to have the same issue. I don't know about igb. But
> I'm not aware of either having hardware emulation in qemu-kvm. So
> unless this issue is reproducible on bare-metal... it's probably not
> a big deal for them.
>
> drivers/net/ethernet/intel/e1000/e1000_main.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c
> b/drivers/net/ethernet/intel/e1000/e1000_main.c index
> 4a32c15..cd26a0a 100644 ---
> a/drivers/net/ethernet/intel/e1000/e1000_main.c +++
> b/drivers/net/ethernet/intel/e1000/e1000_main.c @@ -1814,8 +1814,8 @@
> static void e1000_setup_rctl(struct e1000_adapter *adapter)
> rctl &= ~(3 << E1000_RCTL_MO_SHIFT);
>
> - rctl |= E1000_RCTL_EN | E1000_RCTL_BAM |
> - E1000_RCTL_LBM_NO | E1000_RCTL_RDMTS_HALF |
> + rctl |= E1000_RCTL_BAM | E1000_RCTL_LBM_NO |
> + E1000_RCTL_RDMTS_HALF |
> (hw->mc_filter_type << E1000_RCTL_MO_SHIFT);
>
> if (hw->tbi_compatibility_on == 1)
> @@ -1917,7 +1917,7 @@ static void e1000_configure_rx(struct
> e1000_adapter *adapter) }
>
> /* Enable Receives */
> - ew32(RCTL, rctl);
> + ew32(RCTL, rctl | E1000_RCTL_EN);
> }
>
> /**
generally i like the patch. We should take it in and test it, and I
don't really see any problems with it.
------------------------------------------------------------------------------
Doing More with Less: The Next Generation Virtual Desktop
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops? How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH net-next-2.6] e1000: don't enable dma receives until after dma address has been setup
From: Dean Nelson @ 2011-09-15 18:22 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: netdev@vger.kernel.org, Michael S. Tsirkin, Andy Gospodarek,
Kirsher, Jeffrey T, tushar.n.dave, e1000-devel
In-Reply-To: <20110915102112.0000146b@unknown>
On 09/15/2011 12:21 PM, Jesse Brandeburg wrote:
> On Wed, 14 Sep 2011 17:31:38 -0700
> Dean Nelson<dnelson@redhat.com> wrote:
>
>> Doing an 'ifconfig ethN down' followed by an 'ifconfig ethN up' on a
>> qemu-kvm guest system configured with two e1000 NICs can result in an
>> 'unable to handle kernel paging request at 0000000100000000' or 'bad
>> page map in process ...' or something similar.
>
> <snip>
>
>> The corruption appears to result from the following...
>>
<snip>
>>
>> I realize that in the guest, we're dealing with an e1000 NIC that is
>> software emulated by qemu-kvm. The problem doesn't appear to occur on
>> bare-metal. Andy suspects that this is because in the emulator
>> link-up is essentially instant and traffic can start flowing
>> immediately. Whereas on bare-metal, link-up usually seems to take at
>> least a few milliseconds. And this might be enough to prevent traffic
>> from flowing into the device inside the window where E1000_RCTL_EN is
>> set.
>
> nice analysis dean, yes, we shouldn't enable rx before we have the
> hardware all ready.
Thank you.
> You didn't mention however that the hardware is reset in e1000_down,
> which will clear the RDBAL/RDBAH in real hardware.
You are correct, I did fail to mention the reset. And the clearing of
RDBAL/RDHAH was definitely not happening in the qemu-kvm emulator.
>> So perhaps a modification needs to be made to the qemu-kvm e1000 NIC
>> emulator to delay the link-up. But in defense of the emulator, it
>> seems like a bad idea to enable dma operations before the address of
>> the memory to be involved has been made known.
>
> the hardware reset code in kvm should also reset to default many
> registers (almost all of them in fact) which may also end up solving
> the problem.
Agreed.
>> The following patch no longer enables receives in e1000_setup_rctl()
>> but leaves them however they were. It only enables receives in
>> e1000_configure_rx(), and only after the dma address has been made
>> known to the hardware.
>
> I still like your patch better as it is more correct. We could also
> correct the kvm virtual hardware driver.
The hardware emulator should definitely be doing a proper hardware reset.
>> There are two places where e1000_setup_rctl() gets called. The one in
<snip>
>>
>> The e1000e looks to have the same issue. I don't know about igb. But
>> I'm not aware of either having hardware emulation in qemu-kvm. So
>> unless this issue is reproducible on bare-metal... it's probably not
>> a big deal for them.
>>
<snip>
>
> generally i like the patch. We should take it in and test it, and I
> don't really see any problems with it.
Thanks.
As mentioned above, the e1000e has a similar algorithm, but the
FLAG2_NO_DISABLE_RX complicates it a bit. I have no idea what happens
if receives are enabled while setting RDBAL and RDBAH. Is there any
possibility that the hardware could try to make use of a half-baked
address?
Thanks much for your review of the patch.
Dean
^ permalink raw reply
* net GIT trees on github
From: David Miller @ 2011-09-15 19:05 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA
I finally broke down and started putting some trees up on github.
The plain 'net' tree is up already:
git://github.com/davem330/net.git
And a "net-next.git" will be there shortly.
This is a temporary situation so that I can push out the backlog
a little bit until kernel.org is fully back in service. Once
kernel.org is back I will stop updating these trees.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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] cls_rsvp.h was outdated
From: David Miller @ 2011-09-15 19:06 UTC (permalink / raw)
To: igorm; +Cc: netdev, linux-kernel
In-Reply-To: <59e0c7c0ba5282f35b101e7058fb27fa.squirrel@kondor.etf.bg.ac.rs>
From: "Igor Maravić" <igorm@etf.rs>
Date: Tue, 30 Aug 2011 15:12:55 +0200
> File cls_rsvp.h in /net/sched was outdated. I'm sending you patch for this
> file.
>
> Signed-off-by: Igor Maravić <igorm@etf.rs>
Patch applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/8] bnx2x: fixes
From: David Miller @ 2011-09-15 19:06 UTC (permalink / raw)
To: dmitry; +Cc: netdev
In-Reply-To: <1314698926-24525-1-git-send-email-dmitry@broadcom.com>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Tue, 30 Aug 2011 13:08:38 +0300
> Please consider appling the series of bnx2x fixes to 'net'
All applied, thanks Dmitry.
^ permalink raw reply
* Re: [PATCH v2] tcp: Change possible SYN flooding messages
From: David Miller @ 2011-09-15 19:06 UTC (permalink / raw)
To: eric.dumazet; +Cc: therbert, netdev
In-Reply-To: <1314710504.2935.21.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 30 Aug 2011 15:21:44 +0200
> "Possible SYN flooding on port xxxx " messages can fill logs on servers.
>
> Change logic to log the message only once per listener, and add two new
> SNMP counters to track :
>
> TCPReqQFullDoCookies : number of times a SYNCOOKIE was replied to client
>
> TCPReqQFullDrop : number of times a SYN request was dropped because
> syncookies were not enabled.
>
> Based on a prior patch from Tom Herbert, and suggestions from David.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] Documentation: networking: dmfe.txt: Remove the maintainer of orphan filesystem
From: David Miller @ 2011-09-15 19:07 UTC (permalink / raw)
To: marcos.mage; +Cc: rdunlap, netdev, linux-doc
In-Reply-To: <1314718437-5794-1-git-send-email-marcos.mage@gmail.com>
From: Marcos Paulo de Souza <marcos.mage@gmail.com>
Date: Tue, 30 Aug 2011 12:33:57 -0300
> The dmfe module is a orphan driver, and with this was removed the maintainer
> of the documentation.
>
> Signed-off-by: Marcos Paulo de Souza <marcos.mage@gmail.com>
Applied, but I changed "orphan filesystem" to "orphan networking driver"
since last time I checked dmfe is not a filesystem :)
^ permalink raw reply
* Re: [PATCH] net: Make flow cache namespace-aware
From: David Miller @ 2011-09-15 19:08 UTC (permalink / raw)
To: david.ward; +Cc: netdev, whydna
In-Reply-To: <1314806727-5340-1-git-send-email-david.ward@ll.mit.edu>
From: David Ward <david.ward@ll.mit.edu>
Date: Wed, 31 Aug 2011 12:05:27 -0400
> flow_cache_lookup will return a cached object (or null pointer) that the
> resolver (i.e. xfrm_policy_lookup) previously found for another namespace
> using the same key/family/dir. Instead, make the namespace part of what
> identifies entries in the cache.
>
> As before, flow_entry_valid will return 0 for entries where the namespace
> has been deleted, and they will be removed from the cache the next time
> flow_cache_gc_task is run.
>
> Reported-by: Andrew Dickinson <whydna@whydna.net>
> Signed-off-by: David Ward <david.ward@ll.mit.edu>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6] net: copy userspace buffers on device forwarding
From: David Miller @ 2011-09-15 19:08 UTC (permalink / raw)
To: mst
Cc: herbert, eric.dumazet, mirq-linux, therbert, jpirko, jesse, xma,
linux-kernel, netdev
In-Reply-To: <20110831180328.GA22016@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Wed, 31 Aug 2011 21:03:29 +0300
> dev_forward_skb loops an skb back into host networking
> stack which might hang on the memory indefinitely.
> In particular, this can happen in macvtap in bridged mode.
> Copy the userspace fragments to avoid blocking the
> sender in that case.
>
> As this patch makes skb_copy_ubufs extern now,
> I also added some documentation and made it clear
> the SKBTX_DEV_ZEROCOPY flag automatically instead
> of doing it in all callers. This can be made into a separate
> patch if people feel it's worth it.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: don't clear IFF_XMIT_DST_RELEASE in ether_setup
From: David Miller @ 2011-09-15 19:08 UTC (permalink / raw)
To: nhorman; +Cc: netdev
In-Reply-To: <1316005502-7341-1-git-send-email-nhorman@tuxdriver.com>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Wed, 14 Sep 2011 09:05:02 -0400
> d88733150 introduced the IFF_SKB_TX_SHARING flag, which I unilaterally set in
> ether_setup. In doing this I didn't realize that other flags (such as
> IFF_XMIT_DST_RELEASE) might be set prior to calling the ether_setup routine.
> This patch changes ether_setup to or in SKB_TX_SHARING so as not to
> inadvertently clear other existing flags. Thanks to Pekka Riikonen for pointing
> out my error
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> Reported-by: Pekka Riikonen <priikone@iki.fi>
Applied, thanks Neil.
^ permalink raw reply
* Re: [PATCH 1/1] net/can/af_can.c: Change del_timer to del_timer_sync
From: David Miller @ 2011-09-15 19:07 UTC (permalink / raw)
To: rajan.aggarwal85; +Cc: socketcan, urs.thuermann, netdev
In-Reply-To: <1314784658-23938-1-git-send-email-rajan.aggarwal85@gmail.com>
From: Rajan Aggarwal <rajan.aggarwal85@gmail.com>
Date: Wed, 31 Aug 2011 15:27:38 +0530
> From: Rajan Aggarwal <Rajan Aggarwal rajan.aggarwal85@gmail.com>
>
> This is important for SMP platform to check if timer function is
> executing on other CPU with deleting the timer.
>
> Signed-off-by: Rajan Aggarwal <Rajan Aggarwal rajan.aggarwal85@gmail.com>
Applied, thanks.
^ 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