* Re: [PATCH 2/2] packet: Add fanout support.
From: Eric Dumazet @ 2011-07-05 4:33 UTC (permalink / raw)
To: David Miller; +Cc: victor, netdev
In-Reply-To: <20110704.212014.236340473910292460.davem@davemloft.net>
Le lundi 04 juillet 2011 à 21:20 -0700, David Miller a écrit :
> Fanouts allow packet capturing to be demuxed to a set of AF_PACKET
> sockets. Two fanout policies are implemented:
>
> 1) Hashing based upon skb->rxhash
>
> 2) Pure round-robin
>
> An AF_PACKET socket must be fully bound before it tries to add itself
> to a fanout. All AF_PACKET sockets trying to join the same fanout
> must all have the same bind settings.
>
> Fanouts are identified (within a network namespace) by a 16-bit ID.
> The first socket to try to add itself to a fanout with a particular
> ID, creates that fanout. When the last socket leaves the fanout
> (which happens only when the socket is closed), that fanout is
> destroyed.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> include/linux/if_packet.h | 4 +
> net/packet/af_packet.c | 250 ++++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 249 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/if_packet.h b/include/linux/if_packet.h
> index 7b31863..1efa1cb 100644
> --- a/include/linux/if_packet.h
> +++ b/include/linux/if_packet.h
> @@ -49,6 +49,10 @@ struct sockaddr_ll {
> #define PACKET_VNET_HDR 15
> #define PACKET_TX_TIMESTAMP 16
> #define PACKET_TIMESTAMP 17
> +#define PACKET_FANOUT 18
> +
> +#define PACKET_FANOUT_HASH 0
> +#define PACKET_FANOUT_LB 1
>
> struct tpacket_stats {
> unsigned int tp_packets;
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index bb281bf..7db1e12 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -187,9 +187,11 @@ static int tpacket_snd(struct packet_sock *po, struct msghdr *msg);
>
> static void packet_flush_mclist(struct sock *sk);
>
> +struct packet_fanout;
> struct packet_sock {
> /* struct sock has to be the first member of packet_sock */
> struct sock sk;
> + struct packet_fanout *fanout;
> struct tpacket_stats stats;
> struct packet_ring_buffer rx_ring;
> struct packet_ring_buffer tx_ring;
> @@ -212,6 +214,24 @@ struct packet_sock {
> struct packet_type prot_hook ____cacheline_aligned_in_smp;
> };
>
> +#define PACKET_FANOUT_MAX 2048
> +
> +struct packet_fanout {
> +#ifdef CONFIG_NET_NS
> + struct net *net;
> +#endif
> + int num_members;
> + u16 id;
> + u8 type;
> + u8 pad;
> + atomic_t rr_cur;
> + struct list_head list;
> + struct sock *arr[PACKET_FANOUT_MAX];
Thats about 16Kbytes, yet you use kzalloc()
> + spinlock_t lock;
> + atomic_t sk_ref;
> + struct packet_type prot_hook ____cacheline_aligned_in_smp;
> +};
> +
Maybe use a dynamic array ? I suspect most uses wont even reach 16
sockets anyway...
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Alexey Zaytsev @ 2011-07-05 4:29 UTC (permalink / raw)
To: Eric Dumazet
Cc: Michael Büsch, Andrew Morton, netdev, Gary Zambrano,
bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <1309839928.2720.23.camel@edumazet-laptop>
On Tue, Jul 5, 2011 at 08:25, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 05 juillet 2011 à 08:17 +0400, Alexey Zaytsev a écrit :
>> >
>> Check out starting at packet 302893. 383 _identical_ ACKs were sent
>> out by the b44 machine within 30 milliseconds.
>
>
> As I said, b44 driver lost at least 200 consecutive frames (source says
> recovery takes about 20 ms)
>
> TCP then do its normal job.
>
From my understanding, after a frame is lost, TCP would be waiting for
a retransmit. Or at least, it would not be sending 400 duplicate ACKs
for the single last frame received, right? Let me run tcpdump on the
b44 side now. I'm quite sure I won't see any ACK dups leaving the
stack.
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Eric Dumazet @ 2011-07-05 4:25 UTC (permalink / raw)
To: Alexey Zaytsev
Cc: Michael Büsch, Andrew Morton, netdev, Gary Zambrano,
bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <CAB9v_DGSFAG9V0jqem+tDP3G-N8v6Z+_6oKdPwL-ZwhfhCOZnw@mail.gmail.com>
Le mardi 05 juillet 2011 à 08:17 +0400, Alexey Zaytsev a écrit :
> >
> Check out starting at packet 302893. 383 _identical_ ACKs were sent
> out by the b44 machine within 30 milliseconds.
As I said, b44 driver lost at least 200 consecutive frames (source says
recovery takes about 20 ms)
TCP then do its normal job.
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Eric Dumazet @ 2011-07-05 4:21 UTC (permalink / raw)
To: Alexey Zaytsev
Cc: Michael Büsch, Andrew Morton, netdev, Gary Zambrano,
bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <1309837443.2720.8.camel@edumazet-laptop>
Le mardi 05 juillet 2011 à 05:44 +0200, Eric Dumazet a écrit :
> Maybe we should do instead a fast dequeue of packets (recycling them
> instead of pushing them to upper stack) in case too many packets are
> ready to be delivered, and always make sure NIC has a reserve of
> available buffers for DMA accesses, before it can assert ISTAT_RFO
>
>
Another way would be to add Explicit Congestion Notification when too
many packets are received in a burst, but unfortunately not enough TCP
flows are ECN ready :)
^ permalink raw reply
* [PATCH 2/2] packet: Add fanout support.
From: David Miller @ 2011-07-05 4:20 UTC (permalink / raw)
To: victor; +Cc: netdev
Fanouts allow packet capturing to be demuxed to a set of AF_PACKET
sockets. Two fanout policies are implemented:
1) Hashing based upon skb->rxhash
2) Pure round-robin
An AF_PACKET socket must be fully bound before it tries to add itself
to a fanout. All AF_PACKET sockets trying to join the same fanout
must all have the same bind settings.
Fanouts are identified (within a network namespace) by a 16-bit ID.
The first socket to try to add itself to a fanout with a particular
ID, creates that fanout. When the last socket leaves the fanout
(which happens only when the socket is closed), that fanout is
destroyed.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/linux/if_packet.h | 4 +
net/packet/af_packet.c | 250 ++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 249 insertions(+), 5 deletions(-)
diff --git a/include/linux/if_packet.h b/include/linux/if_packet.h
index 7b31863..1efa1cb 100644
--- a/include/linux/if_packet.h
+++ b/include/linux/if_packet.h
@@ -49,6 +49,10 @@ struct sockaddr_ll {
#define PACKET_VNET_HDR 15
#define PACKET_TX_TIMESTAMP 16
#define PACKET_TIMESTAMP 17
+#define PACKET_FANOUT 18
+
+#define PACKET_FANOUT_HASH 0
+#define PACKET_FANOUT_LB 1
struct tpacket_stats {
unsigned int tp_packets;
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index bb281bf..7db1e12 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -187,9 +187,11 @@ static int tpacket_snd(struct packet_sock *po, struct msghdr *msg);
static void packet_flush_mclist(struct sock *sk);
+struct packet_fanout;
struct packet_sock {
/* struct sock has to be the first member of packet_sock */
struct sock sk;
+ struct packet_fanout *fanout;
struct tpacket_stats stats;
struct packet_ring_buffer rx_ring;
struct packet_ring_buffer tx_ring;
@@ -212,6 +214,24 @@ struct packet_sock {
struct packet_type prot_hook ____cacheline_aligned_in_smp;
};
+#define PACKET_FANOUT_MAX 2048
+
+struct packet_fanout {
+#ifdef CONFIG_NET_NS
+ struct net *net;
+#endif
+ int num_members;
+ u16 id;
+ u8 type;
+ u8 pad;
+ atomic_t rr_cur;
+ struct list_head list;
+ struct sock *arr[PACKET_FANOUT_MAX];
+ spinlock_t lock;
+ atomic_t sk_ref;
+ struct packet_type prot_hook ____cacheline_aligned_in_smp;
+};
+
struct packet_skb_cb {
unsigned int origlen;
union {
@@ -227,6 +247,9 @@ static inline struct packet_sock *pkt_sk(struct sock *sk)
return (struct packet_sock *)sk;
}
+static void __fanout_unlink(struct sock *sk, struct packet_sock *po);
+static void __fanout_link(struct sock *sk, struct packet_sock *po);
+
/* register_prot_hook must be invoked with the po->bind_lock held,
* or from a context in which asynchronous accesses to the packet
* socket is not possible (packet_create()).
@@ -235,7 +258,10 @@ static void register_prot_hook(struct sock *sk)
{
struct packet_sock *po = pkt_sk(sk);
if (!po->running) {
- dev_add_pack(&po->prot_hook);
+ if (po->fanout)
+ __fanout_link(sk, po);
+ else
+ dev_add_pack(&po->prot_hook);
sock_hold(sk);
po->running = 1;
}
@@ -253,7 +279,10 @@ static void __unregister_prot_hook(struct sock *sk, bool sync)
struct packet_sock *po = pkt_sk(sk);
po->running = 0;
- __dev_remove_pack(&po->prot_hook);
+ if (po->fanout)
+ __fanout_unlink(sk, po);
+ else
+ __dev_remove_pack(&po->prot_hook);
__sock_put(sk);
if (sync) {
@@ -388,6 +417,195 @@ static void packet_sock_destruct(struct sock *sk)
sk_refcnt_debug_dec(sk);
}
+static int fanout_rr_next(struct packet_fanout *f)
+{
+ int x = atomic_read(&f->rr_cur) + 1;
+
+ if (x >= f->num_members)
+ x = 0;
+
+ return x;
+}
+
+static struct sock *fanout_demux_hash(struct packet_fanout *f, struct sk_buff *skb)
+{
+ u32 idx, hash = skb->rxhash;
+
+ idx = ((u64)hash * f->num_members) >> 32;
+
+ return f->arr[idx];
+}
+
+static struct sock *fanout_demux_lb(struct packet_fanout *f, struct sk_buff *skb)
+{
+ int cur, old;
+
+ cur = atomic_read(&f->rr_cur);
+ while ((old = atomic_cmpxchg(&f->rr_cur, cur,
+ fanout_rr_next(f))) != cur)
+ cur = old;
+ return f->arr[cur];
+}
+
+static int packet_rcv_fanout_hash(struct sk_buff *skb, struct net_device *dev,
+ struct packet_type *pt, struct net_device *orig_dev)
+{
+ struct packet_fanout *f = pt->af_packet_priv;
+ struct packet_sock *po;
+ struct sock *sk;
+
+ if (!net_eq(dev_net(dev), read_pnet(&f->net))) {
+ kfree_skb(skb);
+ return 0;
+ }
+
+ sk = fanout_demux_hash(f, skb);
+ po = pkt_sk(sk);
+
+ return po->prot_hook.func(skb, dev, &po->prot_hook, orig_dev);
+}
+
+static int packet_rcv_fanout_lb(struct sk_buff *skb, struct net_device *dev,
+ struct packet_type *pt, struct net_device *orig_dev)
+{
+ struct packet_fanout *f = pt->af_packet_priv;
+ struct packet_sock *po;
+ struct sock *sk;
+
+ if (!net_eq(dev_net(dev), read_pnet(&f->net))) {
+ kfree_skb(skb);
+ return 0;
+ }
+
+ sk = fanout_demux_lb(f, skb);
+ po = pkt_sk(sk);
+
+ return po->prot_hook.func(skb, dev, &po->prot_hook, orig_dev);
+}
+
+static DEFINE_MUTEX(fanout_mutex);
+static LIST_HEAD(fanout_list);
+
+static void __fanout_link(struct sock *sk, struct packet_sock *po)
+{
+ struct packet_fanout *f = po->fanout;
+
+ spin_lock(&f->lock);
+ f->arr[f->num_members] = sk;
+ smp_wmb();
+ f->num_members++;
+ spin_unlock(&f->lock);
+}
+
+static void __fanout_unlink(struct sock *sk, struct packet_sock *po)
+{
+ struct packet_fanout *f = po->fanout;
+ int i;
+
+ spin_unlock(&f->lock);
+ for (i = 0; i < f->num_members; i++) {
+ if (f->arr[i] == sk)
+ break;
+ }
+ BUG_ON(i >= f->num_members);
+ f->arr[i] = f->arr[f->num_members - 1];
+ f->num_members--;
+ spin_unlock(&f->lock);
+}
+
+static int fanout_add(struct sock *sk, u16 id, u8 type)
+{
+ struct packet_sock *po = pkt_sk(sk);
+ struct packet_fanout *f, *match;
+ int err;
+
+ switch (type) {
+ case PACKET_FANOUT_HASH:
+ case PACKET_FANOUT_LB:
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (!po->running)
+ return -EINVAL;
+
+ if (po->fanout)
+ return -EALREADY;
+
+ mutex_lock(&fanout_mutex);
+ match = NULL;
+ list_for_each_entry(f, &fanout_list, list) {
+ if (f->id == id &&
+ read_pnet(&f->net) == sock_net(sk)) {
+ match = f;
+ break;
+ }
+ }
+ if (!match) {
+ match = kzalloc(sizeof(*match), GFP_KERNEL);
+ if (match) {
+ write_pnet(&match->net, sock_net(sk));
+ match->id = id;
+ match->type = type;
+ atomic_set(&match->rr_cur, 0);
+ INIT_LIST_HEAD(&match->list);
+ spin_lock_init(&match->lock);
+ atomic_set(&match->sk_ref, 0);
+ match->prot_hook.type = po->prot_hook.type;
+ match->prot_hook.dev = po->prot_hook.dev;
+ switch (type) {
+ case PACKET_FANOUT_HASH:
+ match->prot_hook.func = packet_rcv_fanout_hash;
+ break;
+ case PACKET_FANOUT_LB:
+ match->prot_hook.func = packet_rcv_fanout_lb;
+ break;
+ }
+ match->prot_hook.af_packet_priv = match;
+ dev_add_pack(&match->prot_hook);
+ list_add(&match->list, &fanout_list);
+ }
+ }
+ err = -ENOMEM;
+ if (match) {
+ err = -EINVAL;
+ if (match->type == type &&
+ match->prot_hook.type == po->prot_hook.type &&
+ match->prot_hook.dev == po->prot_hook.dev) {
+ err = -ENOSPC;
+ if (atomic_read(&match->sk_ref) < PACKET_FANOUT_MAX) {
+ __dev_remove_pack(&po->prot_hook);
+ po->fanout = match;
+ atomic_inc(&match->sk_ref);
+ __fanout_link(sk, po);
+ err = 0;
+ }
+ }
+ }
+ mutex_unlock(&fanout_mutex);
+ return err;
+}
+
+static void fanout_release(struct sock *sk)
+{
+ struct packet_sock *po = pkt_sk(sk);
+ struct packet_fanout *f;
+
+ f = po->fanout;
+ if (!f)
+ return;
+
+ po->fanout = NULL;
+
+ mutex_lock(&fanout_mutex);
+ if (atomic_dec_and_test(&f->sk_ref)) {
+ list_del(&f->list);
+ dev_remove_pack(&f->prot_hook);
+ kfree(f);
+ }
+ mutex_unlock(&fanout_mutex);
+}
static const struct proto_ops packet_ops;
@@ -1398,6 +1616,8 @@ static int packet_release(struct socket *sock)
if (po->tx_ring.pg_vec)
packet_set_ring(sk, &req, 1, 1);
+ fanout_release(sk);
+
synchronize_net();
/*
* Now the socket is dead. No more input will appear.
@@ -1421,9 +1641,9 @@ static int packet_release(struct socket *sock)
static int packet_do_bind(struct sock *sk, struct net_device *dev, __be16 protocol)
{
struct packet_sock *po = pkt_sk(sk);
- /*
- * Detach an existing hook if present.
- */
+
+ if (po->fanout)
+ return -EINVAL;
lock_sock(sk);
@@ -2133,6 +2353,17 @@ packet_setsockopt(struct socket *sock, int level, int optname, char __user *optv
po->tp_tstamp = val;
return 0;
}
+ case PACKET_FANOUT:
+ {
+ int val;
+
+ if (optlen != sizeof(val))
+ return -EINVAL;
+ if (copy_from_user(&val, optval, sizeof(val)))
+ return -EFAULT;
+
+ return fanout_add(sk, val & 0xffff, val >> 16);
+ }
default:
return -ENOPROTOOPT;
}
@@ -2231,6 +2462,15 @@ static int packet_getsockopt(struct socket *sock, int level, int optname,
val = po->tp_tstamp;
data = &val;
break;
+ case PACKET_FANOUT:
+ if (len > sizeof(int))
+ len = sizeof(int);
+ val = (po->fanout ?
+ ((u32)po->fanout->id |
+ ((u32)po->fanout->type << 16)) :
+ 0);
+ data = &val;
+ break;
default:
return -ENOPROTOOPT;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/2] packet: Add helpers to register/unregister ->prot_hook
From: David Miller @ 2011-07-05 4:20 UTC (permalink / raw)
To: victor; +Cc: netdev
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/packet/af_packet.c | 103 +++++++++++++++++++++++++++--------------------
1 files changed, 59 insertions(+), 44 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 461b16f..bb281bf 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -222,6 +222,55 @@ struct packet_skb_cb {
#define PACKET_SKB_CB(__skb) ((struct packet_skb_cb *)((__skb)->cb))
+static inline struct packet_sock *pkt_sk(struct sock *sk)
+{
+ return (struct packet_sock *)sk;
+}
+
+/* register_prot_hook must be invoked with the po->bind_lock held,
+ * or from a context in which asynchronous accesses to the packet
+ * socket is not possible (packet_create()).
+ */
+static void register_prot_hook(struct sock *sk)
+{
+ struct packet_sock *po = pkt_sk(sk);
+ if (!po->running) {
+ dev_add_pack(&po->prot_hook);
+ sock_hold(sk);
+ po->running = 1;
+ }
+}
+
+/* {,__}unregister_prot_hook() must be invoked with the po->bind_lock
+ * held. If the sync parameter is true, we will temporarily drop
+ * the po->bind_lock and do a synchronize_net to make sure no
+ * asynchronous packet processing paths still refer to the elements
+ * of po->prot_hook. If the sync parameter is false, it is the
+ * callers responsibility to take care of this.
+ */
+static void __unregister_prot_hook(struct sock *sk, bool sync)
+{
+ struct packet_sock *po = pkt_sk(sk);
+
+ po->running = 0;
+ __dev_remove_pack(&po->prot_hook);
+ __sock_put(sk);
+
+ if (sync) {
+ spin_unlock(&po->bind_lock);
+ synchronize_net();
+ spin_lock(&po->bind_lock);
+ }
+}
+
+static void unregister_prot_hook(struct sock *sk, bool sync)
+{
+ struct packet_sock *po = pkt_sk(sk);
+
+ if (po->running)
+ __unregister_prot_hook(sk, sync);
+}
+
static inline __pure struct page *pgv_to_page(void *addr)
{
if (is_vmalloc_addr(addr))
@@ -324,11 +373,6 @@ static inline void packet_increment_head(struct packet_ring_buffer *buff)
buff->head = buff->head != buff->frame_max ? buff->head+1 : 0;
}
-static inline struct packet_sock *pkt_sk(struct sock *sk)
-{
- return (struct packet_sock *)sk;
-}
-
static void packet_sock_destruct(struct sock *sk)
{
skb_queue_purge(&sk->sk_error_queue);
@@ -1337,15 +1381,7 @@ static int packet_release(struct socket *sock)
spin_unlock_bh(&net->packet.sklist_lock);
spin_lock(&po->bind_lock);
- if (po->running) {
- /*
- * Remove from protocol table
- */
- po->running = 0;
- po->num = 0;
- __dev_remove_pack(&po->prot_hook);
- __sock_put(sk);
- }
+ unregister_prot_hook(sk, false);
if (po->prot_hook.dev) {
dev_put(po->prot_hook.dev);
po->prot_hook.dev = NULL;
@@ -1392,15 +1428,7 @@ static int packet_do_bind(struct sock *sk, struct net_device *dev, __be16 protoc
lock_sock(sk);
spin_lock(&po->bind_lock);
- if (po->running) {
- __sock_put(sk);
- po->running = 0;
- po->num = 0;
- spin_unlock(&po->bind_lock);
- dev_remove_pack(&po->prot_hook);
- spin_lock(&po->bind_lock);
- }
-
+ unregister_prot_hook(sk, true);
po->num = protocol;
po->prot_hook.type = protocol;
if (po->prot_hook.dev)
@@ -1413,9 +1441,7 @@ static int packet_do_bind(struct sock *sk, struct net_device *dev, __be16 protoc
goto out_unlock;
if (!dev || (dev->flags & IFF_UP)) {
- dev_add_pack(&po->prot_hook);
- sock_hold(sk);
- po->running = 1;
+ register_prot_hook(sk);
} else {
sk->sk_err = ENETDOWN;
if (!sock_flag(sk, SOCK_DEAD))
@@ -1542,9 +1568,7 @@ static int packet_create(struct net *net, struct socket *sock, int protocol,
if (proto) {
po->prot_hook.type = proto;
- dev_add_pack(&po->prot_hook);
- sock_hold(sk);
- po->running = 1;
+ register_prot_hook(sk);
}
spin_lock_bh(&net->packet.sklist_lock);
@@ -2240,9 +2264,7 @@ static int packet_notifier(struct notifier_block *this, unsigned long msg, void
if (dev->ifindex == po->ifindex) {
spin_lock(&po->bind_lock);
if (po->running) {
- __dev_remove_pack(&po->prot_hook);
- __sock_put(sk);
- po->running = 0;
+ __unregister_prot_hook(sk, false);
sk->sk_err = ENETDOWN;
if (!sock_flag(sk, SOCK_DEAD))
sk->sk_error_report(sk);
@@ -2259,11 +2281,8 @@ static int packet_notifier(struct notifier_block *this, unsigned long msg, void
case NETDEV_UP:
if (dev->ifindex == po->ifindex) {
spin_lock(&po->bind_lock);
- if (po->num && !po->running) {
- dev_add_pack(&po->prot_hook);
- sock_hold(sk);
- po->running = 1;
- }
+ if (po->num)
+ register_prot_hook(sk);
spin_unlock(&po->bind_lock);
}
break;
@@ -2530,10 +2549,8 @@ static int packet_set_ring(struct sock *sk, struct tpacket_req *req,
was_running = po->running;
num = po->num;
if (was_running) {
- __dev_remove_pack(&po->prot_hook);
po->num = 0;
- po->running = 0;
- __sock_put(sk);
+ __unregister_prot_hook(sk, false);
}
spin_unlock(&po->bind_lock);
@@ -2564,11 +2581,9 @@ static int packet_set_ring(struct sock *sk, struct tpacket_req *req,
mutex_unlock(&po->pg_vec_lock);
spin_lock(&po->bind_lock);
- if (was_running && !po->running) {
- sock_hold(sk);
- po->running = 1;
+ if (was_running) {
po->num = num;
- dev_add_pack(&po->prot_hook);
+ register_prot_hook(sk);
}
spin_unlock(&po->bind_lock);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 0/2] AF_PACKET fanout support
From: David Miller @ 2011-07-05 4:20 UTC (permalink / raw)
To: victor; +Cc: netdev
This is a fully functional version, I've tested both hash and
load-balance modes successfully. I plan to commit this to
net-next-2.6 very soon.
Below is a test program that other people can play with
if they want. It basically creates 4 threads, and creates
an AF_PACKET fanout amongst them. Each thread prints out
it's pid in parentheses every time it receives 10 packets.
After each thread processes 10,000 packets, it exits.
Try things like "./test eth0 hash", "./test eth0 lb", etc.
Signed-off-by: David S. Miller <davem@davemloft.net>
--------------------
#include <stddef.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <unistd.h>
#include <linux/if_ether.h>
#include <linux/if_packet.h>
#include <net/if.h>
static const char *device_name;
static int fanout_type;
static int fanout_id;
#ifndef PACKET_FANOUT
#define PACKET_FANOUT 18
#define PACKET_FANOUT_HASH 0
#define PACKET_FANOUT_LB 1
#endif
static int setup_socket(void)
{
int err, fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_IP));
struct sockaddr_ll ll;
struct ifreq ifr;
int fanout_arg;
if (fd < 0) {
perror("socket");
return EXIT_FAILURE;
}
memset(&ifr, 0, sizeof(ifr));
strcpy(ifr.ifr_name, device_name);
err = ioctl(fd, SIOCGIFINDEX, &ifr);
if (err < 0) {
perror("SIOCGIFINDEX");
return EXIT_FAILURE;
}
memset(&ll, 0, sizeof(ll));
ll.sll_family = AF_PACKET;
ll.sll_ifindex = ifr.ifr_ifindex;
err = bind(fd, (struct sockaddr *) &ll, sizeof(ll));
if (err < 0) {
perror("bind");
return EXIT_FAILURE;
}
fanout_arg = (fanout_id | (fanout_type << 16));
err = setsockopt(fd, SOL_PACKET, PACKET_FANOUT,
&fanout_arg, sizeof(fanout_arg));
if (err) {
perror("setsockopt");
return EXIT_FAILURE;
}
return fd;
}
static void fanout_thread(void)
{
int fd = setup_socket();
int limit = 10000;
if (fd < 0)
exit(fd);
while (limit-- > 0) {
char buf[1600];
int err;
err = read(fd, buf, sizeof(buf));
if (err < 0) {
perror("read");
exit(EXIT_FAILURE);
}
if ((limit % 10) == 0)
fprintf(stdout, "(%d) \n", getpid());
}
fprintf(stdout, "%d: Received 10000 packets\n", getpid());
close(fd);
exit(0);
}
int main(int argc, char **argp)
{
int fd, err;
int i;
if (argc != 3) {
fprintf(stderr, "Usage: %s INTERFACE {hash|lb}\n", argp[0]);
return EXIT_FAILURE;
}
if (!strcmp(argp[2], "hash"))
fanout_type = PACKET_FANOUT_HASH;
else if (!strcmp(argp[2], "lb"))
fanout_type = PACKET_FANOUT_LB;
else {
fprintf(stderr, "Unknown fanout type [%s]\n", argp[2]);
exit(EXIT_FAILURE);
}
device_name = argp[1];
fanout_id = getpid() & 0xffff;
for (i = 0; i < 4; i++) {
pid_t pid = fork();
switch (pid) {
case 0:
fanout_thread();
case -1:
perror("fork");
exit(EXIT_FAILURE);
}
}
for (i = 0; i < 4; i++) {
int status;
wait(&status);
}
return 0;
}
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Alexey Zaytsev @ 2011-07-05 4:18 UTC (permalink / raw)
To: Eric Dumazet
Cc: Michael Büsch, Andrew Morton, netdev, Gary Zambrano,
bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <CAB9v_DGSFAG9V0jqem+tDP3G-N8v6Z+_6oKdPwL-ZwhfhCOZnw@mail.gmail.com>
On Tue, Jul 5, 2011 at 08:17, Alexey Zaytsev <alexey.zaytsev@gmail.com> wrote:
> On Tue, Jul 5, 2011 at 08:14, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> Le mardi 05 juillet 2011 à 06:11 +0200, Eric Dumazet a écrit :
>>> Le mardi 05 juillet 2011 à 07:56 +0400, Alexey Zaytsev a écrit :
>>> > On Tue, Jul 5, 2011 at 07:44, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>> > >
>>> > > I dont care about duplicate acks at this point.
>>> > >
>>> > > Thats a separate issue (TCP layer)
>>> > >
>>> >
>>> > Maybe some tx packets are just sent out more then once? Or a single
>>> > packet is sent out instead of some other packets?
>>> > The delays between two dups is short, and they come in bursts, up to a
>>> > few hundreds of duplicate packets at a time.
>>> >
>>>
>>> Thats a completely different problem. SSH is very expensive for your
>>> receiver (your dump1 file has small packets (560 bytes)), and it cannot
>>> cope with the stress.
>>>
>>> You're filling the b44 rx ring, and b44 driver has no choice to zap 200
>>> packets at once. This sure is a problem for tcp, as it stalls the thing.
>>>
>>> You could avoid this by doing this at b44 machine (the receiver)
>>>
>>> echo "4096 32768 87380" >/proc/sys/net/ipv4/tcp_rmem
>>>
>>> So that sender wont be able to push so many packets
>>
>> You can also try using more packets in rx ring : (default is 200
>> packets, limit ~511)
>>
>> ethtool -G eth0 rx 400
>>
>>
> Check out starting at packet 302893. 383 _identical_ ACKs were sent
> out by the b44 machine within 30 milliseconds.
In dump1.pcap, that is.
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Alexey Zaytsev @ 2011-07-05 4:17 UTC (permalink / raw)
To: Eric Dumazet
Cc: Michael Büsch, Andrew Morton, netdev, Gary Zambrano,
bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <1309839258.2720.17.camel@edumazet-laptop>
On Tue, Jul 5, 2011 at 08:14, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 05 juillet 2011 à 06:11 +0200, Eric Dumazet a écrit :
>> Le mardi 05 juillet 2011 à 07:56 +0400, Alexey Zaytsev a écrit :
>> > On Tue, Jul 5, 2011 at 07:44, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > >
>> > > I dont care about duplicate acks at this point.
>> > >
>> > > Thats a separate issue (TCP layer)
>> > >
>> >
>> > Maybe some tx packets are just sent out more then once? Or a single
>> > packet is sent out instead of some other packets?
>> > The delays between two dups is short, and they come in bursts, up to a
>> > few hundreds of duplicate packets at a time.
>> >
>>
>> Thats a completely different problem. SSH is very expensive for your
>> receiver (your dump1 file has small packets (560 bytes)), and it cannot
>> cope with the stress.
>>
>> You're filling the b44 rx ring, and b44 driver has no choice to zap 200
>> packets at once. This sure is a problem for tcp, as it stalls the thing.
>>
>> You could avoid this by doing this at b44 machine (the receiver)
>>
>> echo "4096 32768 87380" >/proc/sys/net/ipv4/tcp_rmem
>>
>> So that sender wont be able to push so many packets
>
> You can also try using more packets in rx ring : (default is 200
> packets, limit ~511)
>
> ethtool -G eth0 rx 400
>
>
Check out starting at packet 302893. 383 _identical_ ACKs were sent
out by the b44 machine within 30 milliseconds.
>
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Eric Dumazet @ 2011-07-05 4:14 UTC (permalink / raw)
To: Alexey Zaytsev
Cc: Michael Büsch, Andrew Morton, netdev, Gary Zambrano,
bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <1309839068.2720.15.camel@edumazet-laptop>
Le mardi 05 juillet 2011 à 06:11 +0200, Eric Dumazet a écrit :
> Le mardi 05 juillet 2011 à 07:56 +0400, Alexey Zaytsev a écrit :
> > On Tue, Jul 5, 2011 at 07:44, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > >
> > > I dont care about duplicate acks at this point.
> > >
> > > Thats a separate issue (TCP layer)
> > >
> >
> > Maybe some tx packets are just sent out more then once? Or a single
> > packet is sent out instead of some other packets?
> > The delays between two dups is short, and they come in bursts, up to a
> > few hundreds of duplicate packets at a time.
> >
>
> Thats a completely different problem. SSH is very expensive for your
> receiver (your dump1 file has small packets (560 bytes)), and it cannot
> cope with the stress.
>
> You're filling the b44 rx ring, and b44 driver has no choice to zap 200
> packets at once. This sure is a problem for tcp, as it stalls the thing.
>
> You could avoid this by doing this at b44 machine (the receiver)
>
> echo "4096 32768 87380" >/proc/sys/net/ipv4/tcp_rmem
>
> So that sender wont be able to push so many packets
You can also try using more packets in rx ring : (default is 200
packets, limit ~511)
ethtool -G eth0 rx 400
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Eric Dumazet @ 2011-07-05 4:11 UTC (permalink / raw)
To: Alexey Zaytsev
Cc: Michael Büsch, Andrew Morton, netdev, Gary Zambrano,
bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <CAB9v_DFYGyYiXGfMCXn_WDeGTKz8BZPYBCuaDj_a+5VAG3Jn=g@mail.gmail.com>
Le mardi 05 juillet 2011 à 07:56 +0400, Alexey Zaytsev a écrit :
> On Tue, Jul 5, 2011 at 07:44, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > I dont care about duplicate acks at this point.
> >
> > Thats a separate issue (TCP layer)
> >
>
> Maybe some tx packets are just sent out more then once? Or a single
> packet is sent out instead of some other packets?
> The delays between two dups is short, and they come in bursts, up to a
> few hundreds of duplicate packets at a time.
>
Thats a completely different problem. SSH is very expensive for your
receiver (your dump1 file has small packets (560 bytes)), and it cannot
cope with the stress.
You're filling the b44 rx ring, and b44 driver has no choice to zap 200
packets at once. This sure is a problem for tcp, as it stalls the thing.
You could avoid this by doing this at b44 machine (the receiver)
echo "4096 32768 87380" >/proc/sys/net/ipv4/tcp_rmem
So that sender wont be able to push so many packets
> > Do you still have memory scribbles ?
> Yes.
OK
>
> >
> > I wonder if the problem is not coming from the "fast recovery" added in
> > commit 32737e934a952c (PATCH: b44 Handle RX FIFO overflow better
> > (simplified))
> >
>
> I've tested back to 2.6.27. I did not test all releases of course, so
> maybe this was fixed, and then broken again.
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Alexey Zaytsev @ 2011-07-05 3:56 UTC (permalink / raw)
To: Eric Dumazet
Cc: Michael Büsch, Andrew Morton, netdev, Gary Zambrano,
bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <1309837443.2720.8.camel@edumazet-laptop>
On Tue, Jul 5, 2011 at 07:44, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 05 juillet 2011 à 02:29 +0400, Alexey Zaytsev a écrit :
>> On Tue, Jul 5, 2011 at 00:25, Alexey Zaytsev <alexey.zaytsev@gmail.com> wrote:
>> > On Mon, Jul 4, 2011 at 19:12, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> >> Le lundi 04 juillet 2011 à 16:43 +0200, Michael Büsch a écrit :
>> >>> On Mon, 4 Jul 2011 16:27:26 +0200
>> >>> Michael Büsch <m@bues.ch> wrote:
>> >>> > We do this in b43, which has exactly the same DMA engine.
>> >>>
>> >>> (Ok, it turns out we don't do this in b43 (We only do it on the TX side).
>> >>> But that's a bug. We should do a wmb() on the RX side before advancing the
>> >>> descriptor ring pointer.)
>> >>
>> >> I am wondering what happens if RX ring is set to 64, and we receive
>> >> exactly 64 buffers in one round, B44_DMARX_PTR wont change at all ?
>> >>
>> >> Alexey, could you try this patch please ?
>> >
>> > Sorry, did not help.
>> >
>>
>> Ran a few rounds of tcpdump. Seeing a significant number or duplicate
>> ACKs from the problematic machine. Not seeing them when testing
>> between this machine and an other linux box. Or the illumos machine
>> and the other linux box.
>>
>> Dumps are available here:
>>
>> http://zaytsev.su/tmp/caps/
>>
>> dump1-3 - between the problematic machine an the illumos box,
>> collected on illumos side. All show dups.
>> dump5 - between an other linux box and the illumos machine, no dups.
>> Collcted on the illumos side.
>> dump-linux - between 2 linux machines, collected on the
>> non-problematic side. No dups, no corruptions.
>>
>> 192.168.0.33 - the problematic machine.
>> 192.168.0.72 - the illumos machine.
>> 192.168.0.122 - an other linux machine.
>
> ??
>
> I dont care about duplicate acks at this point.
>
> Thats a separate issue (TCP layer)
>
Maybe some tx packets are just sent out more then once? Or a single
packet is sent out instead of some other packets?
The delays between two dups is short, and they come in bursts, up to a
few hundreds of duplicate packets at a time.
> Do you still have memory scribbles ?
Yes.
>
> I wonder if the problem is not coming from the "fast recovery" added in
> commit 32737e934a952c (PATCH: b44 Handle RX FIFO overflow better
> (simplified))
>
I've tested back to 2.6.27. I did not test all releases of course, so
maybe this was fixed, and then broken again.
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Eric Dumazet @ 2011-07-05 3:44 UTC (permalink / raw)
To: Alexey Zaytsev
Cc: Michael Büsch, Andrew Morton, netdev, Gary Zambrano,
bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <CAB9v_DFFX6cHAFBSOGDJRniehJ6pYD7Z5XG6ygTGHy8j=z+U0g@mail.gmail.com>
Le mardi 05 juillet 2011 à 02:29 +0400, Alexey Zaytsev a écrit :
> On Tue, Jul 5, 2011 at 00:25, Alexey Zaytsev <alexey.zaytsev@gmail.com> wrote:
> > On Mon, Jul 4, 2011 at 19:12, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >> Le lundi 04 juillet 2011 à 16:43 +0200, Michael Büsch a écrit :
> >>> On Mon, 4 Jul 2011 16:27:26 +0200
> >>> Michael Büsch <m@bues.ch> wrote:
> >>> > We do this in b43, which has exactly the same DMA engine.
> >>>
> >>> (Ok, it turns out we don't do this in b43 (We only do it on the TX side).
> >>> But that's a bug. We should do a wmb() on the RX side before advancing the
> >>> descriptor ring pointer.)
> >>
> >> I am wondering what happens if RX ring is set to 64, and we receive
> >> exactly 64 buffers in one round, B44_DMARX_PTR wont change at all ?
> >>
> >> Alexey, could you try this patch please ?
> >
> > Sorry, did not help.
> >
>
> Ran a few rounds of tcpdump. Seeing a significant number or duplicate
> ACKs from the problematic machine. Not seeing them when testing
> between this machine and an other linux box. Or the illumos machine
> and the other linux box.
>
> Dumps are available here:
>
> http://zaytsev.su/tmp/caps/
>
> dump1-3 - between the problematic machine an the illumos box,
> collected on illumos side. All show dups.
> dump5 - between an other linux box and the illumos machine, no dups.
> Collcted on the illumos side.
> dump-linux - between 2 linux machines, collected on the
> non-problematic side. No dups, no corruptions.
>
> 192.168.0.33 - the problematic machine.
> 192.168.0.72 - the illumos machine.
> 192.168.0.122 - an other linux machine.
??
I dont care about duplicate acks at this point.
Thats a separate issue (TCP layer)
Do you still have memory scribbles ?
I wonder if the problem is not coming from the "fast recovery" added in
commit 32737e934a952c (PATCH: b44 Handle RX FIFO overflow better
(simplified))
Maybe we should do instead a fast dequeue of packets (recycling them
instead of pushing them to upper stack) in case too many packets are
ready to be delivered, and always make sure NIC has a reserve of
available buffers for DMA accesses, before it can assert ISTAT_RFO
^ permalink raw reply
* Re: [PATCH net-next] net/wireless: ipw2x00: Use helpers from linux/etherdevice.h
From: David Miller @ 2011-07-05 3:31 UTC (permalink / raw)
To: tklauser; +Cc: linville, netdev, linux-wireless
In-Reply-To: <1309773622-28510-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Mon, 4 Jul 2011 12:00:22 +0200
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: vxge: Use is_multicast_ether_addr helper
From: David Miller @ 2011-07-05 3:31 UTC (permalink / raw)
To: tklauser; +Cc: jdmason, netdev
In-Reply-To: <1309773484-27514-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Mon, 4 Jul 2011 11:58:04 +0200
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: ewrk3: Use helpers from linux/etherdevice.h
From: David Miller @ 2011-07-05 3:31 UTC (permalink / raw)
To: tklauser; +Cc: netdev
In-Reply-To: <1309773382-26609-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Mon, 4 Jul 2011 11:56:22 +0200
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: depca: Use helpers from linux/etherdevice.h
From: David Miller @ 2011-07-05 3:31 UTC (permalink / raw)
To: tklauser; +Cc: netdev
In-Reply-To: <1309773353-26210-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Mon, 4 Jul 2011 11:55:53 +0200
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: rionet: Use is_multicast_ether_addr
From: David Miller @ 2011-07-05 3:31 UTC (permalink / raw)
To: tklauser; +Cc: netdev
In-Reply-To: <1309773294-25395-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Mon, 4 Jul 2011 11:54:54 +0200
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: iseries_veth: Use is_unicast_ether_addr helper
From: David Miller @ 2011-07-05 3:31 UTC (permalink / raw)
To: tklauser; +Cc: netdev
In-Reply-To: <1309773123-24049-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Mon, 4 Jul 2011 11:52:03 +0200
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: de4x5: Use helpers from linux/etherdevice.h
From: David Miller @ 2011-07-05 3:31 UTC (permalink / raw)
To: tklauser; +Cc: grundler, netdev
In-Reply-To: <1309772893-22585-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Mon, 4 Jul 2011 11:48:13 +0200
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: igb: Use is_multicast_ether_addr helper
From: David Miller @ 2011-07-05 3:31 UTC (permalink / raw)
To: tklauser; +Cc: e1000-devel, netdev
In-Reply-To: <1309773015-23598-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Mon, 4 Jul 2011 11:50:15 +0200
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
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] net: e1000e: Use is_multicast_ether_addr helper
From: David Miller @ 2011-07-05 3:30 UTC (permalink / raw)
To: tklauser; +Cc: e1000-devel, netdev
In-Reply-To: <1309772824-22157-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Mon, 4 Jul 2011 11:47:04 +0200
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
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: [PATCHv2 0/2] Minor documentation updates for ip-related tunables
From: David Miller @ 2011-07-05 2:27 UTC (permalink / raw)
To: makc; +Cc: linux-sctp, netdev
In-Reply-To: <20110705015718.32777815DBB1@regina.usersys.redhat.com>
From: Max Matveev <makc@redhat.com>
Date: Tue, 5 Jul 2011 11:57:18 +1000 (EST)
> Confusion about the way SCTP uses its rmem and wmem tunables
> prompted a documentation revision.
>
> v2: incorporate suggestions by Shan Wei and Neil Horman.
>
> Max Matveev (2):
> Update description of net.sctp.sctp_rmem and net.sctp.sctp_wmem tunables
> Update documented default values for various TCP/UDP tunables
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH v2 1/2] Update description of net.sctp.sctp_rmem and net.sctp.sctp_wmem tunables
From: Shan Wei @ 2011-07-05 2:01 UTC (permalink / raw)
To: Max Matveev; +Cc: linux-sctp, netdev
In-Reply-To: <20110705015723.8B226815DBB1@regina.usersys.redhat.com>
Max Matveev wrote, at 06/20/2011 04:08 PM:
> sctp does not use second and third ("default" and "max") values
> of sctp_rmem tunable. The format is the same as tcp_rmem
> but the meaning is different so make the documentation explicit to
> avoid confusion.
>
> sctp_wmem is not used at all.
>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
> Signed-off-by: Max Matveev <makc@redhat.com>
Reviewed-by: Shan Wei <shanwei@cn.fujitsu.com>
--
Best Regards
-----
Shan Wei
^ permalink raw reply
* Re: [PATCH 1/2] Update description of net.sctp.sctp_rmem and net.sctp.sctp_wmem tunables
From: Max Matveev @ 2011-07-05 2:00 UTC (permalink / raw)
To: Neil Horman; +Cc: linux-sctp, netdev
In-Reply-To: <20110704145454.GA10310@hmsreliant.think-freely.org>
On Mon, 4 Jul 2011 10:54:54 -0400, Neil Horman wrote:
nhorman> On Mon, Jun 20, 2011 at 06:08:10PM +1000, Max Matveev wrote:
>> sctp_rmem - vector of 3 INTEGERs: min, default, max
>> - See tcp_rmem for a description.
>> + Only the first value ("min") is used, "default" and "max" are
>> + ignored and may be removed in the future versions.
>> +
nhorman> Its accurate to say that only the first value is usd
nhorman> currently, but because of the way this sysctl is contructed
nhorman> (its used by the sysctl_rmem pointer in the sctp_prot
nhorman> struct, which expects an array of three integers in the
nhorman> commong __sk_mem_schedule function), we wont' be removing
nhorman> the other two values.
Technically it can be just a single integer - UDP does use it
that way but I'm not going to argue, v2 of the patch removed
that bit.
max
^ 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