* [PATCH 0/6] Misc driver fixes for 2.6.32
From: Ralf Baechle @ 2009-11-05 15:25 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Daney, Atsushi Nemoto, Julia Lawall, Greg Kroah-Hartman,
devel, David Brownell, spi-devel-general, linux-kernel,
linux-mips, netdev
This is a series of patches which
o 1/6, 2/6, 3/6: Fixes for the Octeon ethernet driver in drivers/staging.
The Octeon is a MIPS-based SOC so with permisson from Greg I'm merging
these via the MIPS tree.
o 4/6: A fix to a MIPS-specific SPI driver. Posted before, no comments
were received.
o 5/6: A fix to the resource allocation to the framebuffer of the MIPS-
based SGI O2 and i686-based Visual Workstation. Also posted before, no
comments were received.
o 6/6: A fix to the serial driver for the BCM63xx which is a MIPS-based
SOC.
Ralf
^ permalink raw reply
* Re: [PATCH 03/25] mlx4_core: add multi-function communicationchannel
From: Roland Dreier @ 2009-11-05 18:01 UTC (permalink / raw)
To: Liran Liss
Cc: Yevgeny Petrilin, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Tziporet Koren
In-Reply-To: <2ED289D4E09FBD4D92D911E869B97FDD0166C9B7-ia22CT07NJfiMCgWhms8HQC/G2K4zDHf@public.gmane.org>
> > And HZ/1000 is going to be 0 if HZ is less than 1000 ... so this is just
> > going to run continuously in the polling case.
> This is what we want as long as there are more pending commands.
So then instead of HZ/1000 just use 0 always? I don't see a reason why
you would want to wait if HZ >= 1000 and not wait if HZ is < 1000.
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC] TCP Multicast Extension
From: Michael Chan @ 2009-11-05 18:12 UTC (permalink / raw)
To: netdev
Hi,
I am planning to implement a TCP extension named "Single-source
multicast optimization", proposed in
S. Liang and D. Cheriton "TCP-SMO: Extending TCP to Support
Medium-Scale Multicast Applications", Proc. IEEE Infocom 2002.
A sample use case of this extension would be a single data source
doing bulk transfer to a number of replication sites. In this case,
TCP-SMO provides for multicast of the bulk transfer and the
optimization of transport-level retransmissions using the conventional
and well-tested TCP implementation.
In a nutshell, a TCP multicast session with a single source (server)
consists of two parts: (1) an IP multicast session, and (2) a set of
ordinary TCP connections, one between the server and each multicast
client. Data is sent via IP multicast, while the individual TCP
connections are for retransmissions and client-to-server
communication.
The required changes to the kernel TCP implementation are as follows:
Server side:
1) Creating a TCP-SMO "master socket" that keeps track of statistics
of the unchanged, per-client TCP socket
2) Modifying connection establishment so when a new client connects,
the socket created is associated to the master socket
3) Modifying the ACK path so that clients' ACKs are delivered to
master socket for processing
4) Creating a multicast group associated with the master socket
Client side:
1) Add in ability to associate multicast traffic (from server) to the
TCP connection with server
2) Joining and leaving multicast groups with the TCP socket
Before any coding, I stumbled on the following issues and thought it'd
be best to learn from the experts:
1) Is someone already doing something similar in the kernel space?
2) The original implementation was for the 2.2 kernel and had a lot of
"#ifdef CONFIG_TCP_MULTICAST strewn across the different tcp-related
constructs, including the accept, init, recvmsg, sendmsg functions and
significant additions to struct sock. The 2.6 kernel put the
tcp-specific stuff into struct tcp_sock. Given that the kernel coding
style asked for reducing number of #ifdef's in non-header code, is it
considered acceptable practice to modify this struct and the numerous
tcp functions, or should a new struct tcp_smo_sock containing a
tcp_sock as the first member be a better alternative? From a design
perspective, it seems like defining a new struct is "cleaner". But
SMO, when enabled, really re-uses / modifies existing TCP behavior. It
isn't clear to me how code reuse can be achieved without some amount
of #ifdef's in the existing implementation.
3) My goal is to make as little changes as possible to the
implementation and to provide an easy way to enable SMO from
userspace. Therefore, I'm thinking of adding TCP-level socket options
for SMO-related operations. The alternative of a different
tcp_smo_sock struct (as explained above) seems to indicate changes to
the socket() system call as well, because I will need to change the
sock being allocated. So I really doubt that approach from the
viewpoint of easy user adoption.
4) Is this in fact a fool's errand since such an extension does not
conform to the networking subsystem's development practices and hence
won't ever get accepted?
Any comments are greatly appreciated!
Thanks,
Michael
^ permalink raw reply
* RE: [PATCH 03/25] mlx4_core: add multi-functioncommunicationchannel
From: Liran Liss @ 2009-11-05 18:16 UTC (permalink / raw)
To: Roland Dreier; +Cc: Yevgeny Petrilin, linux-rdma, netdev, Tziporet Koren
In-Reply-To: <adatyx8c0lu.fsf@roland-alpha.cisco.com>
Right - will fix.
10x,
--Liran
-----Original Message-----
From: Roland Dreier [mailto:rdreier@cisco.com]
Sent: Thursday, November 05, 2009 8:01 PM
To: Liran Liss
Cc: Yevgeny Petrilin; linux-rdma@vger.kernel.org;
netdev@vger.kernel.org; Tziporet Koren
Subject: Re: [PATCH 03/25] mlx4_core: add
multi-functioncommunicationchannel
> > And HZ/1000 is going to be 0 if HZ is less than 1000 ... so this is
just > > going to run continuously in the polling case.
> This is what we want as long as there are more pending commands.
So then instead of HZ/1000 just use 0 always? I don't see a reason why
you would want to wait if HZ >= 1000 and not wait if HZ is < 1000.
- R.
^ permalink raw reply
* Re: [PATCH 2.6.33/1 00/12] WiMAX patches for 2.6.33 (batch #1)
From: Inaky Perez-Gonzalez @ 2009-11-05 18:17 UTC (permalink / raw)
To: David Miller; +Cc: netdev, wimax
In-Reply-To: <20091104.222450.149379897.davem@davemloft.net>
On Wed, 2009-11-04 at 22:24 -0800, David Miller wrote:
> From: Inaky Perez-Gonzalez <inaky@linux.intel.com>
> Date: Wed, 4 Nov 2009 13:39:36 -0800
>
> > Please pull from:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/inaky/wimax.git
>
> Well you screwed up the patch posting and you screwed up the
> GIT tree too :-/
>
> This git tree is not based upon a clone of net-next-2.6, instead
> it's a mish-mash of net-next-2.6 and some by-hand net-2.6
> pulls you've done yourself.
Yes I did -- I didn't give you the linux-2.6.33.y branch; my apologies.
The master branch is my testing tree and yes, that is not for merging.
So this pull should be against:
REPO git://git.kernel.org/pub/scm/linux/kernel/git/inaky/wimax.git
BRANCH linux-2.6.33.y
which is purely based off net-next-2.6
$ git merge-base net-next-2.6/master linux-2.6.33.y
eb2ff967a587a4a784fd2390f38e324a5bec01ec
$ git log -1 eb2ff967a587a4a784fd2390f38e324a5bec01ec
eb2ff967a587a4a784fd2390f38e324a5bec01ec xfrm: remove skb_icv_walk
> Do NOT do this.
>
> I even saw a random kbuild: change in there as well, which
> also shouldn't have been there.
>
> Fix up your tree and make it pull cleanly before submitting this
> work again.
>
> Also, when you give ma GIT URL you have to give me the branch to pull
> from at the end of the URL, if I just give that URL without the branch
> specifier to GIT for the pull it's going to fail.
This was my mistake too -- request-pull fails to detect the branch
properly when it is not given an end argument that matches HEAD and I
failed to realize that I was generating cover letter messages without
the branch.
This happened because I was breaking up the whole list of commits in
smaller chunks. Another item for the checklist.
It's maddening that I always manage to screw up somewhere :( My
apologies again.
^ permalink raw reply
* netfilter 02/02: xt_connlimit: fix regression caused by zero family value
From: Patrick McHardy @ 2009-11-05 18:23 UTC (permalink / raw)
To: David S. Miller; +Cc: Netfilter Development Mailinglist, Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 02.diff --]
[-- Type: text/x-patch, Size: 2010 bytes --]
commit 0b3645af59740e4da29a18b96d8eaf68ddd2cea4
Author: Jan Engelhardt <jengelh@medozas.de>
Date: Thu Nov 5 15:02:25 2009 +0100
netfilter: xt_connlimit: fix regression caused by zero family value
Commit v2.6.28-rc1~7172~1092~2 was slightly incomplete; not all
instances of par->match->family were changed to par->family.
Netfilter bugzilla #610.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/netfilter/xt_connlimit.c b/net/netfilter/xt_connlimit.c
index 6809809..38f03f7 100644
--- a/net/netfilter/xt_connlimit.c
+++ b/net/netfilter/xt_connlimit.c
@@ -103,7 +103,7 @@ static int count_them(struct xt_connlimit_data *data,
const struct nf_conntrack_tuple *tuple,
const union nf_inet_addr *addr,
const union nf_inet_addr *mask,
- const struct xt_match *match)
+ u_int8_t family)
{
const struct nf_conntrack_tuple_hash *found;
struct xt_connlimit_conn *conn;
@@ -113,8 +113,7 @@ static int count_them(struct xt_connlimit_data *data,
bool addit = true;
int matches = 0;
-
- if (match->family == NFPROTO_IPV6)
+ if (family == NFPROTO_IPV6)
hash = &data->iphash[connlimit_iphash6(addr, mask)];
else
hash = &data->iphash[connlimit_iphash(addr->ip & mask->ip)];
@@ -157,8 +156,7 @@ static int count_them(struct xt_connlimit_data *data,
continue;
}
- if (same_source_net(addr, mask, &conn->tuple.src.u3,
- match->family))
+ if (same_source_net(addr, mask, &conn->tuple.src.u3, family))
/* same source network -> be counted! */
++matches;
nf_ct_put(found_ct);
@@ -207,7 +205,7 @@ connlimit_mt(const struct sk_buff *skb, const struct xt_match_param *par)
spin_lock_bh(&info->data->lock);
connections = count_them(info->data, tuple_ptr, &addr,
- &info->mask, par->match);
+ &info->mask, par->family);
spin_unlock_bh(&info->data->lock);
if (connections < 0) {
^ permalink raw reply related
* netfilter 01/02: nf_nat: fix NAT issue in 2.6.30.4+
From: Patrick McHardy @ 2009-11-05 18:23 UTC (permalink / raw)
To: David S. Miller; +Cc: Netfilter Development Mailinglist, Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 468 bytes --]
Hi Dave,
the following two patches fix two netfilter bugs:
- incorrect sequence number tracking in TCP conntrack in combination
with NAT helpers that enlarge the packet, causing incorrectly
detected out of window packets
- a regression in the connlimit match
The first patch is quite large for this late in the release cycle, so
if you prefer, I'll queue it up for net-next instead.
I'll pass on both to -stable once they hit upstream.
Please apply, thanks!
[-- Attachment #2: 01.diff --]
[-- Type: text/x-patch, Size: 10269 bytes --]
commit 0132f9835c1c19a369954e1eb56dca80a1382369
Author: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Date: Thu Sep 17 13:05:15 2009 +0200
netfilter: nf_nat: fix NAT issue in 2.6.30.4+
Vitezslav Samel discovered that since 2.6.30.4+ active FTP can not work
over NAT. The "cause" of the problem was a fix of unacknowledged data
detection with NAT (commit a3a9f79e361e864f0e9d75ebe2a0cb43d17c4272).
However, actually, that fix uncovered a long standing bug in TCP conntrack:
when NAT was enabled, we simply updated the max of the right edge of
the segments we have seen (td_end), by the offset NAT produced with
changing IP/port in the data. However, we did not update the other parameter
(td_maxend) which is affected by the NAT offset. Thus that could drift
away from the correct value and thus resulted breaking active FTP.
The patch below fixes the issue by *not* updating the conntrack parameters
from NAT, but instead taking into account the NAT offsets in conntrack in a
consistent way. (Updating from NAT would be more harder and expensive because
it'd need to re-calculate parameters we already calculated in conntrack.)
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h
index cbdd628..5cf7270 100644
--- a/include/net/netfilter/nf_conntrack.h
+++ b/include/net/netfilter/nf_conntrack.h
@@ -255,11 +255,9 @@ static inline bool nf_ct_kill(struct nf_conn *ct)
}
/* These are for NAT. Icky. */
-/* Update TCP window tracking data when NAT mangles the packet */
-extern void nf_conntrack_tcp_update(const struct sk_buff *skb,
- unsigned int dataoff,
- struct nf_conn *ct, int dir,
- s16 offset);
+extern s16 (*nf_ct_nat_offset)(const struct nf_conn *ct,
+ enum ip_conntrack_dir dir,
+ u32 seq);
/* Fake conntrack entry for untracked connections */
extern struct nf_conn nf_conntrack_untracked;
diff --git a/include/net/netfilter/nf_nat_helper.h b/include/net/netfilter/nf_nat_helper.h
index 237a961..4222220 100644
--- a/include/net/netfilter/nf_nat_helper.h
+++ b/include/net/netfilter/nf_nat_helper.h
@@ -32,4 +32,8 @@ extern int (*nf_nat_seq_adjust_hook)(struct sk_buff *skb,
* to port ct->master->saved_proto. */
extern void nf_nat_follow_master(struct nf_conn *ct,
struct nf_conntrack_expect *this);
+
+extern s16 nf_nat_get_offset(const struct nf_conn *ct,
+ enum ip_conntrack_dir dir,
+ u32 seq);
#endif
diff --git a/net/ipv4/netfilter/nf_nat_core.c b/net/ipv4/netfilter/nf_nat_core.c
index 68afc6e..fe1a644 100644
--- a/net/ipv4/netfilter/nf_nat_core.c
+++ b/net/ipv4/netfilter/nf_nat_core.c
@@ -750,6 +750,8 @@ static int __init nf_nat_init(void)
BUG_ON(nfnetlink_parse_nat_setup_hook != NULL);
rcu_assign_pointer(nfnetlink_parse_nat_setup_hook,
nfnetlink_parse_nat_setup);
+ BUG_ON(nf_ct_nat_offset != NULL);
+ rcu_assign_pointer(nf_ct_nat_offset, nf_nat_get_offset);
return 0;
cleanup_extend:
@@ -764,6 +766,7 @@ static void __exit nf_nat_cleanup(void)
nf_ct_extend_unregister(&nat_extend);
rcu_assign_pointer(nf_nat_seq_adjust_hook, NULL);
rcu_assign_pointer(nfnetlink_parse_nat_setup_hook, NULL);
+ rcu_assign_pointer(nf_ct_nat_offset, NULL);
synchronize_net();
}
diff --git a/net/ipv4/netfilter/nf_nat_helper.c b/net/ipv4/netfilter/nf_nat_helper.c
index 09172a6..f9520fa 100644
--- a/net/ipv4/netfilter/nf_nat_helper.c
+++ b/net/ipv4/netfilter/nf_nat_helper.c
@@ -73,6 +73,28 @@ adjust_tcp_sequence(u32 seq,
DUMP_OFFSET(this_way);
}
+/* Get the offset value, for conntrack */
+s16 nf_nat_get_offset(const struct nf_conn *ct,
+ enum ip_conntrack_dir dir,
+ u32 seq)
+{
+ struct nf_conn_nat *nat = nfct_nat(ct);
+ struct nf_nat_seq *this_way;
+ s16 offset;
+
+ if (!nat)
+ return 0;
+
+ this_way = &nat->seq[dir];
+ spin_lock_bh(&nf_nat_seqofs_lock);
+ offset = after(seq, this_way->correction_pos)
+ ? this_way->offset_after : this_way->offset_before;
+ spin_unlock_bh(&nf_nat_seqofs_lock);
+
+ return offset;
+}
+EXPORT_SYMBOL_GPL(nf_nat_get_offset);
+
/* Frobs data inside this packet, which is linear. */
static void mangle_contents(struct sk_buff *skb,
unsigned int dataoff,
@@ -189,11 +211,6 @@ nf_nat_mangle_tcp_packet(struct sk_buff *skb,
adjust_tcp_sequence(ntohl(tcph->seq),
(int)rep_len - (int)match_len,
ct, ctinfo);
- /* Tell TCP window tracking about seq change */
- nf_conntrack_tcp_update(skb, ip_hdrlen(skb),
- ct, CTINFO2DIR(ctinfo),
- (int)rep_len - (int)match_len);
-
nf_conntrack_event_cache(IPCT_NATSEQADJ, ct);
}
return 1;
@@ -415,12 +432,7 @@ nf_nat_seq_adjust(struct sk_buff *skb,
tcph->seq = newseq;
tcph->ack_seq = newack;
- if (!nf_nat_sack_adjust(skb, tcph, ct, ctinfo))
- return 0;
-
- nf_conntrack_tcp_update(skb, ip_hdrlen(skb), ct, dir, seqoff);
-
- return 1;
+ return nf_nat_sack_adjust(skb, tcph, ct, ctinfo);
}
/* Setup NAT on this expected conntrack so it follows master. */
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index b371098..805b6a9 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -1350,6 +1350,11 @@ err_stat:
return ret;
}
+s16 (*nf_ct_nat_offset)(const struct nf_conn *ct,
+ enum ip_conntrack_dir dir,
+ u32 seq);
+EXPORT_SYMBOL_GPL(nf_ct_nat_offset);
+
int nf_conntrack_init(struct net *net)
{
int ret;
@@ -1367,6 +1372,9 @@ int nf_conntrack_init(struct net *net)
/* For use by REJECT target */
rcu_assign_pointer(ip_ct_attach, nf_conntrack_attach);
rcu_assign_pointer(nf_ct_destroy, destroy_conntrack);
+
+ /* Howto get NAT offsets */
+ rcu_assign_pointer(nf_ct_nat_offset, NULL);
}
return 0;
diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
index 97a82ba..ba2b769 100644
--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -492,6 +492,21 @@ static void tcp_sack(const struct sk_buff *skb, unsigned int dataoff,
}
}
+#ifdef CONFIG_NF_NAT_NEEDED
+static inline s16 nat_offset(const struct nf_conn *ct,
+ enum ip_conntrack_dir dir,
+ u32 seq)
+{
+ typeof(nf_ct_nat_offset) get_offset = rcu_dereference(nf_ct_nat_offset);
+
+ return get_offset != NULL ? get_offset(ct, dir, seq) : 0;
+}
+#define NAT_OFFSET(pf, ct, dir, seq) \
+ (pf == NFPROTO_IPV4 ? nat_offset(ct, dir, seq) : 0)
+#else
+#define NAT_OFFSET(pf, ct, dir, seq) 0
+#endif
+
static bool tcp_in_window(const struct nf_conn *ct,
struct ip_ct_tcp *state,
enum ip_conntrack_dir dir,
@@ -506,6 +521,7 @@ static bool tcp_in_window(const struct nf_conn *ct,
struct ip_ct_tcp_state *receiver = &state->seen[!dir];
const struct nf_conntrack_tuple *tuple = &ct->tuplehash[dir].tuple;
__u32 seq, ack, sack, end, win, swin;
+ s16 receiver_offset;
bool res;
/*
@@ -519,11 +535,16 @@ static bool tcp_in_window(const struct nf_conn *ct,
if (receiver->flags & IP_CT_TCP_FLAG_SACK_PERM)
tcp_sack(skb, dataoff, tcph, &sack);
+ /* Take into account NAT sequence number mangling */
+ receiver_offset = NAT_OFFSET(pf, ct, !dir, ack - 1);
+ ack -= receiver_offset;
+ sack -= receiver_offset;
+
pr_debug("tcp_in_window: START\n");
pr_debug("tcp_in_window: ");
nf_ct_dump_tuple(tuple);
- pr_debug("seq=%u ack=%u sack=%u win=%u end=%u\n",
- seq, ack, sack, win, end);
+ pr_debug("seq=%u ack=%u+(%d) sack=%u+(%d) win=%u end=%u\n",
+ seq, ack, receiver_offset, sack, receiver_offset, win, end);
pr_debug("tcp_in_window: sender end=%u maxend=%u maxwin=%u scale=%i "
"receiver end=%u maxend=%u maxwin=%u scale=%i\n",
sender->td_end, sender->td_maxend, sender->td_maxwin,
@@ -613,8 +634,8 @@ static bool tcp_in_window(const struct nf_conn *ct,
pr_debug("tcp_in_window: ");
nf_ct_dump_tuple(tuple);
- pr_debug("seq=%u ack=%u sack =%u win=%u end=%u\n",
- seq, ack, sack, win, end);
+ pr_debug("seq=%u ack=%u+(%d) sack=%u+(%d) win=%u end=%u\n",
+ seq, ack, receiver_offset, sack, receiver_offset, win, end);
pr_debug("tcp_in_window: sender end=%u maxend=%u maxwin=%u scale=%i "
"receiver end=%u maxend=%u maxwin=%u scale=%i\n",
sender->td_end, sender->td_maxend, sender->td_maxwin,
@@ -700,7 +721,7 @@ static bool tcp_in_window(const struct nf_conn *ct,
before(seq, sender->td_maxend + 1) ?
after(end, sender->td_end - receiver->td_maxwin - 1) ?
before(sack, receiver->td_end + 1) ?
- after(ack, receiver->td_end - MAXACKWINDOW(sender)) ? "BUG"
+ after(sack, receiver->td_end - MAXACKWINDOW(sender) - 1) ? "BUG"
: "ACK is under the lower bound (possible overly delayed ACK)"
: "ACK is over the upper bound (ACKed data not seen yet)"
: "SEQ is under the lower bound (already ACKed data retransmitted)"
@@ -715,39 +736,6 @@ static bool tcp_in_window(const struct nf_conn *ct,
return res;
}
-#ifdef CONFIG_NF_NAT_NEEDED
-/* Update sender->td_end after NAT successfully mangled the packet */
-/* Caller must linearize skb at tcp header. */
-void nf_conntrack_tcp_update(const struct sk_buff *skb,
- unsigned int dataoff,
- struct nf_conn *ct, int dir,
- s16 offset)
-{
- const struct tcphdr *tcph = (const void *)skb->data + dataoff;
- const struct ip_ct_tcp_state *sender = &ct->proto.tcp.seen[dir];
- const struct ip_ct_tcp_state *receiver = &ct->proto.tcp.seen[!dir];
- __u32 end;
-
- end = segment_seq_plus_len(ntohl(tcph->seq), skb->len, dataoff, tcph);
-
- spin_lock_bh(&ct->lock);
- /*
- * We have to worry for the ack in the reply packet only...
- */
- if (ct->proto.tcp.seen[dir].td_end + offset == end)
- ct->proto.tcp.seen[dir].td_end = end;
- ct->proto.tcp.last_end = end;
- spin_unlock_bh(&ct->lock);
- pr_debug("tcp_update: sender end=%u maxend=%u maxwin=%u scale=%i "
- "receiver end=%u maxend=%u maxwin=%u scale=%i\n",
- sender->td_end, sender->td_maxend, sender->td_maxwin,
- sender->td_scale,
- receiver->td_end, receiver->td_maxend, receiver->td_maxwin,
- receiver->td_scale);
-}
-EXPORT_SYMBOL_GPL(nf_conntrack_tcp_update);
-#endif
-
#define TH_FIN 0x01
#define TH_SYN 0x02
#define TH_RST 0x04
^ permalink raw reply related
* [PATCH 1/2] udp: cleanup __udp4_lib_mcast_deliver
From: Lucian Adrian Grijincu @ 2009-11-05 18:33 UTC (permalink / raw)
To: netdev; +Cc: opurdila
[-- Attachment #1: Type: text/plain, Size: 371 bytes --]
__udp4_lib_mcast_deliver always returned 0.
It's caller can return 0 explicitly to make things clearer.
Also, we don't need the spin_lock() on the hslot to free the skb.
Signed-off-by: Lucian Adrian Grijincu <lgrijincu@ixiacom.com>
---
net/ipv4/udp.c | 57 +++++++++++++++++++++++++++++--------------------------
1 files changed, 30 insertions(+), 27 deletions(-)
[-- Attachment #2: 0001-udp-cleanup-__udp4_lib_mcast_deliver.patch --]
[-- Type: text/plain, Size: 2479 bytes --]
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 4274c1c..425b2d4 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1198,12 +1198,12 @@ drop:
* Note: called only from the BH handler context,
* so we don't need to lock the hashes.
*/
-static int __udp4_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
+static void __udp4_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
struct udphdr *uh,
__be32 saddr, __be32 daddr,
struct udp_table *udptable)
{
- struct sock *sk;
+ struct sock *sk, *sknext;
struct udp_hslot *hslot = udp_hashslot(udptable, net, ntohs(uh->dest));
int dif;
@@ -1211,31 +1211,32 @@ static int __udp4_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
sk = sk_nulls_head(&hslot->head);
dif = skb->dev->ifindex;
sk = udp_v4_mcast_next(net, sk, uh->dest, daddr, uh->source, saddr, dif);
- if (sk) {
- struct sock *sknext = NULL;
-
- do {
- struct sk_buff *skb1 = skb;
-
- sknext = udp_v4_mcast_next(net, sk_nulls_next(sk), uh->dest,
- daddr, uh->source, saddr,
- dif);
- if (sknext)
- skb1 = skb_clone(skb, GFP_ATOMIC);
-
- if (skb1) {
- int ret = udp_queue_rcv_skb(sk, skb1);
- if (ret > 0)
- /* we should probably re-process instead
- * of dropping packets here. */
- kfree_skb(skb1);
- }
- sk = sknext;
- } while (sknext);
- } else
+ if (!sk) {
+ spin_unlock(&hslot->lock);
consume_skb(skb);
+ return;
+ }
+
+ do {
+ struct sk_buff *skb1 = skb;
+
+ sknext = udp_v4_mcast_next(net, sk_nulls_next(sk), uh->dest,
+ daddr, uh->source, saddr,
+ dif);
+ if (sknext)
+ skb1 = skb_clone(skb, GFP_ATOMIC);
+
+ if (skb1) {
+ int ret = udp_queue_rcv_skb(sk, skb1);
+ if (ret > 0)
+ /* we should probably re-process instead
+ * of dropping packets here. */
+ kfree_skb(skb1);
+ }
+ sk = sknext;
+ } while (sknext);
spin_unlock(&hslot->lock);
- return 0;
+ return;
}
/* Initialize UDP checksum. If exited with zero value (success),
@@ -1314,9 +1315,11 @@ int __udp4_lib_rcv(struct sk_buff *skb, struct udp_table *udptable,
saddr = ip_hdr(skb)->saddr;
daddr = ip_hdr(skb)->daddr;
- if (rt->rt_flags & (RTCF_BROADCAST|RTCF_MULTICAST))
- return __udp4_lib_mcast_deliver(net, skb, uh,
+ if (rt->rt_flags & (RTCF_BROADCAST|RTCF_MULTICAST)) {
+ __udp4_lib_mcast_deliver(net, skb, uh,
saddr, daddr, udptable);
+ return 0;
+ }
sk = __udp4_lib_lookup_skb(skb, uh->source, uh->dest, udptable);
^ permalink raw reply related
* [PATCH 2/2] udp: cleanup __udp6_lib_mcast_deliver
From: Lucian Adrian Grijincu @ 2009-11-05 18:33 UTC (permalink / raw)
To: netdev; +Cc: opurdila
[-- Attachment #1: Type: text/plain, Size: 446 bytes --]
__udp6_lib_mcast_deliver always returned 0.
It's caller can return 0 explicitly to make things clearer.
Also, we don't need the spin_lock() on the hslot to free the skb.
kfree_skb() assumes that the frame is being dropped after a failure
and notes that. Replace it with consume_skb().
Signed-off-by: Lucian Adrian Grijincu <lgrijincu@ixiacom.com>
---
net/ipv6/udp.c | 16 +++++++++-------
1 files changed, 9 insertions(+), 7 deletions(-)
[-- Attachment #2: 0002-udp-cleanup-__udp6_lib_mcast_deliver.patch --]
[-- Type: text/plain, Size: 1494 bytes --]
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index d3b59d7..5f17fef 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -446,7 +446,7 @@ static struct sock *udp_v6_mcast_next(struct net *net, struct sock *sk,
* Note: called only from the BH handler context,
* so we don't need to lock the hashes.
*/
-static int __udp6_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
+static void __udp6_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
struct in6_addr *saddr, struct in6_addr *daddr,
struct udp_table *udptable)
{
@@ -460,8 +460,9 @@ static int __udp6_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
dif = inet6_iif(skb);
sk = udp_v6_mcast_next(net, sk, uh->dest, daddr, uh->source, saddr, dif);
if (!sk) {
- kfree_skb(skb);
- goto out;
+ spin_unlock(&hslot->lock);
+ consume_skb(skb);
+ return;
}
sk2 = sk;
@@ -483,9 +484,8 @@ static int __udp6_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
else
sk_add_backlog(sk, skb);
bh_unlock_sock(sk);
-out:
+
spin_unlock(&hslot->lock);
- return 0;
}
static inline int udp6_csum_init(struct sk_buff *skb, struct udphdr *uh,
@@ -568,9 +568,11 @@ int __udp6_lib_rcv(struct sk_buff *skb, struct udp_table *udptable,
/*
* Multicast receive code
*/
- if (ipv6_addr_is_multicast(daddr))
- return __udp6_lib_mcast_deliver(net, skb,
+ if (ipv6_addr_is_multicast(daddr)) {
+ __udp6_lib_mcast_deliver(net, skb,
saddr, daddr, udptable);
+ return 0;
+ }
/* Unicast */
^ permalink raw reply related
* Re: [PATCH net-next-2.6] mac80211: Speedup ieee80211_remove_interfaces()
From: Johannes Berg @ 2009-11-05 18:40 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Linux Netdev List, John W. Linville
In-Reply-To: <4AF2A3B0.4030100@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1833 bytes --]
On Thu, 2009-11-05 at 11:06 +0100, Eric Dumazet wrote:
> Speedup ieee80211_remove_interfaces() by factorizing synchronize_rcu() calls
Jouni will be pleased for his testing... :)
Looks good to me. Nice simplification too.
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
johannes
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> net/mac80211/iface.c | 14 +++++---------
> 1 files changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
> index 14f10eb..a445f50 100644
> --- a/net/mac80211/iface.c
> +++ b/net/mac80211/iface.c
> @@ -852,22 +852,18 @@ void ieee80211_if_remove(struct ieee80211_sub_if_data *sdata)
> void ieee80211_remove_interfaces(struct ieee80211_local *local)
> {
> struct ieee80211_sub_if_data *sdata, *tmp;
> + LIST_HEAD(unreg_list);
>
> ASSERT_RTNL();
>
> + mutex_lock(&local->iflist_mtx);
> list_for_each_entry_safe(sdata, tmp, &local->interfaces, list) {
> - /*
> - * we cannot hold the iflist_mtx across unregister_netdevice,
> - * but we only need to hold it for list modifications to lock
> - * out readers since we're under the RTNL here as all other
> - * writers.
> - */
> - mutex_lock(&local->iflist_mtx);
> list_del(&sdata->list);
> - mutex_unlock(&local->iflist_mtx);
>
> - unregister_netdevice(sdata->dev);
> + unregister_netdevice_queue(sdata->dev, &unreg_list);
> }
> + mutex_unlock(&local->iflist_mtx);
> + unregister_netdevice_many(&unreg_list);
> }
>
> static u32 ieee80211_idle_off(struct ieee80211_local *local,
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: netfilter 02/02: xt_connlimit: fix regression caused by zero family value
From: Jan Engelhardt @ 2009-11-05 18:45 UTC (permalink / raw)
To: Patrick McHardy
Cc: David S. Miller, Netfilter Development Mailinglist,
Linux Netdev List
In-Reply-To: <4AF31818.3030103@trash.net>
On Thursday 2009-11-05 19:23, Patrick McHardy wrote:
>
> netfilter: xt_connlimit: fix regression caused by zero family value
>
> Commit v2.6.28-rc1~7172~1092~2 was slightly incomplete; not all
> instances of par->match->family were changed to par->family.
>
> Netfilter bugzilla #610.
Hold it.
git would never output ~7172~1092~2 because ~8266 would be much simpler.
I originally wrote "Commit v2.6.28-rc1~717^2~109^2~2", but one of your
programs seems to eat commit messages or more.
(BTW, are not inline patches preferred for reply? Attachments do not
automatically get quoted and I have to export it, reimport it, and
have it filtered through perl to add a >.)
^ permalink raw reply
* Re: [PATCH torvalds-2.6] cdc_ether: additional Ericsson MBM PID's to the whitelist
From: Torgny Johansson @ 2009-11-05 19:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev, saurin.shah
In-Reply-To: <20091104.052517.238507016.davem@davemloft.net>
Excellent, thanks alot!
Do you know if this will make it into 2.6.32 or is it too late?
/Torgny
On Wed, Nov 4, 2009 at 2:25 PM, David Miller <davem@davemloft.net> wrote:
> From: Torgny Johansson <torgny.johansson@gmail.com>
> Date: Tue, 3 Nov 2009 22:28:05 +0100
>
>> Trying with another e-mail client to see if that works better. I've
>> sent it to my own gmail first and if I "view original" in gmail the
>> patch works and applies cleanly after downloading it so I'm hoping
>> it will work for you guys too.
>
> Looks good, applied to net-2.6, thanks!
>
^ permalink raw reply
* [PATCH] netdev: Fix compile error in Octeon MGMT driver.
From: David Daney @ 2009-11-05 19:38 UTC (permalink / raw)
To: ralf, linux-mips, netdev; +Cc: David Daney
Explicitly include linux/capability.h. Under some configurations it
wasn't being indirectly included.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
---
This fixes a minor problem for the (already approved) patches that
Ralf has queued for 2.6.33. It should probably be added to Ralf's
queue.
drivers/net/octeon/octeon_mgmt.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/octeon/octeon_mgmt.c b/drivers/net/octeon/octeon_mgmt.c
index 83a636d..050538b 100644
--- a/drivers/net/octeon/octeon_mgmt.c
+++ b/drivers/net/octeon/octeon_mgmt.c
@@ -6,6 +6,7 @@
* Copyright (C) 2009 Cavium Networks
*/
+#include <linux/capability.h>
#include <linux/dma-mapping.h>
#include <linux/init.h>
#include <linux/platform_device.h>
--
1.6.0.6
^ permalink raw reply related
* Re: [net-next-2.6 PATCH RFC] TCPCT part 1d: generate Responder Cookie
From: William Allen Simpson @ 2009-11-05 19:44 UTC (permalink / raw)
To: Eric Dumazet
Cc: paulmck, Linux Kernel Developers, Linux Kernel Network Developers
In-Reply-To: <4AF2D0E0.1040903@gmail.com>
Eric Dumazet wrote:
> William Allen Simpson a écrit :
>> As you suggest, I'll use the _bh suffix everywhere until every i is dotted
>> and t is crossed. Then, check for efficiency later after thorough
>> analysis by experts such as yourself.
>>
>> This code will be hit on every SYN and SYNACK that has a cookie option.
>> But it's just prior to a CPU intensive sha_transform -- in comparison,
>> it's trivial.
>>
> I think you misunderstood my advice ;)
>
Yes, I misunderstood, but it's clear now. As I have to re-spin the whole
kit and kaboodle after the recent net-next crashing bug fixes, I'll post
another complete set tomorrow to the net list.
Thanks again (for all messages).
^ permalink raw reply
* Re: netconsole: tulip: possible remote DoS? due to kernel freeze on heavy RX traffic after Order-1 allocation failure
From: Matt Mackall @ 2009-11-05 19:49 UTC (permalink / raw)
To: Tobias Diedrich; +Cc: Grant Grundler, Kyle McMartin, netdev, linux-kernel
In-Reply-To: <20091105113106.GA4373@yumi.tdiedrich.de>
On Thu, 2009-11-05 at 12:31 +0100, Tobias Diedrich wrote:
> On one of my rootservers, which is using the tulip driver for the
> onboard network interface, I am seeing Order-1 allocation failures
> on heavy RX traffic, which usually hang the machine.
> As in I'm unable to ping it and after forcing a reboot using the
> management interface I don't see the allocation failure message in
> /var/log/kern.log, even though I saw (parts) of it over the
> netconsole.
>
> Unfortunately the netconsole target is not on the LAN, but a
> different rootserver on the internet a few hops away, which means
> bursts of udp Packets are lossy and can get reordered...
>
> I first thought this was introduced in 2.6.31, but it is only easier
> to trigger there. Reducing vm.min_free_pages made it easy enough to
> trigger also on 2.6.30.
>
> Example from netconsole log:
> |perl: page allocation failure. order:1, mode:0x20
> |Pid: 3541, comm: perl Tainted: G W 2.6.30.9-tomodachi #16
> |Call Trace:
> | [<c013e56d>] ? __alloc_pages_internal+0x353/0x36f
> | [<c0154f2c>] ? cache_alloc_refill+0x2ab/0x544
> | [<c0355479>] ? dev_alloc_skb+0x11/0x25
> | [<c015526f>] ? __kmalloc_track_caller+0xaa/0xf9
> | [<c0354ae5>] ? __alloc_skb+0x48/0xff
> | [<c0355479>] ? dev_alloc_skb+0x11/0x25
> | [<c02d4ba9>] ? tulip_refill_rx+0x3c/0x115
> | [<c02d4fff>] ? tulip_poll+0x37d/0x416
> | [<c0359763>] ? net_rx_action+0x6b/0x12f
> | [<c0121ad7>] ? __do_softirq+0x4e/0xbf
> | [<c0121a89>] ? __do_softirq+0x0/0xbf
> | <IRQ> [<c0107700>] ? do_IRQ+0x53/0x63
> | [<c0106610>] ? common_interrupt+0x30/0x38
I don't see anything in this trace to implicate netconsole? This is the
normal network receive path running out of input buffers then running
into memory fragmentation.
--
http://selenic.com : development and support for Mercurial and Linux
^ permalink raw reply
* Re: [PATCH 08/25] mlx4_core: fix buggy parsing of reserved eq cap
From: Roland Dreier @ 2009-11-05 20:00 UTC (permalink / raw)
To: Yevgeny Petrilin
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
liranl-VPRAkNaXOzVS1MOuV/RT9w, tziporet-VPRAkNaXOzVS1MOuV/RT9w
In-Reply-To: <4AF19E2C.6060604-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org>
> - dev_cap->reserved_eqs = 1 << (field & 0xf);
> + dev_cap->reserved_eqs = field & 0xf;
This patch looks good to apply right now. Is it OK for me to make this
"From: Liran Liss <liranl-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org>" and add "Signed-off-by:
Yevgeny Petrilin <yevgenyp-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org>"?
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 08/25] mlx4_core: fix buggy parsing of reserved eq cap
From: Yevgeny Petrilin @ 2009-11-05 20:09 UTC (permalink / raw)
To: Roland Dreier
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Liran Liss, Tziporet Koren
In-Reply-To: <adaws2468tq.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
> > - dev_cap->reserved_eqs = 1 << (field & 0xf);
> > + dev_cap->reserved_eqs = field & 0xf;
>
>This patch looks good to apply right now. Is it OK for me to make this
>"From: Liran Liss <liranl-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org>" and add "Signed-off-by:
>Yevgeny Petrilin <yevgenyp-VPRAkNaXOzVS1MOuV/RT9w@public.gmane.org>"?
Yes, but
I am currently working on fixing the patches according to comments
received so far,
And thought to resubmit the entire patch set.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 08/25] mlx4_core: fix buggy parsing of reserved eq cap
From: Roland Dreier @ 2009-11-05 20:10 UTC (permalink / raw)
To: Yevgeny Petrilin
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Liran Liss, Tziporet Koren
In-Reply-To: <2ED289D4E09FBD4D92D911E869B97FDD0166CEF4-ia22CT07NJfiMCgWhms8HQC/G2K4zDHf@public.gmane.org>
> I am currently working on fixing the patches according to comments
> received so far,
> And thought to resubmit the entire patch set.
That's a good idea, but you can just drop this one and I'll take it
independent of SRIOV support (since it really is independent).
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 08/25] mlx4_core: fix buggy parsing of reserved eq cap
From: Yevgeny Petrilin @ 2009-11-05 20:14 UTC (permalink / raw)
To: Roland Dreier
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Liran Liss, Tziporet Koren
In-Reply-To: <adaskcs68bx.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
>That's a good idea, but you can just drop this one and I'll take it
independent of SRIOV support (since it really is independent).
OK
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] netdev: Fix compile error in Octeon MGMT driver.
From: Ralf Baechle @ 2009-11-05 20:45 UTC (permalink / raw)
To: David Daney; +Cc: linux-mips, netdev
In-Reply-To: <1257449912-27978-1-git-send-email-ddaney@caviumnetworks.com>
On Thu, Nov 05, 2009 at 11:38:32AM -0800, David Daney wrote:
> Explicitly include linux/capability.h. Under some configurations it
> wasn't being indirectly included.
>
> Signed-off-by: David Daney <ddaney@caviumnetworks.com>
> ---
> This fixes a minor problem for the (already approved) patches that
> Ralf has queued for 2.6.33. It should probably be added to Ralf's
> queue.
>
> drivers/net/octeon/octeon_mgmt.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Folded into the existing patch. Thanks!
Ralf
^ permalink raw reply
* Re: [rfc 4/4] igb: expose 82576 bandiwidth allocation
From: Alexander Duyck @ 2009-11-05 23:00 UTC (permalink / raw)
To: Simon Horman
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Kirsher, Jeffrey T, Arnd Bergmann
In-Reply-To: <20091105010628.148945886@vergenet.net>
Simon Horman wrote:
> The 82576 has support for bandwidth allocation to VFs.
>
> Contrary to the documentation in the 82576 datasheet v2.41 this
> appears to work as follows:
>
> * The ratio supplied is always proportional to 1Gbit/s,
> regardless of if the link speed.
> * The ratio supplied is an upper-bound on bandwidth available
> to the VF, not a minimun guarantee
>
> This patch exposes bandwidth control to userspace through a simple
> per-device (PF) sysfs file, bandwidth_allocation.
>
> * The file contains a whitespace delimited list of values, one per VF.
> * The first value corresponds to the first VF and so on.
> * Valid values are integers from 0 to 1000
> * A value of 0 indicates that bandwidth_allocation is disabled.
> * Other values indicate the allocated bandwidth, in 1/1000ths of a gigabit/s
>
> e.g. The following for a PF with 4 VFs allocates ~20Mbits/ to VF 1,
> ~100Mbit/s to VF 2, and leave the other 2 VFs with no allocation.
>
> echo "20 100 0 0" > /sys/class/net/eth3/device/bandwidth_allocation
>
> This interface is intended to allow testing of the hardware feature.
> There are ongoing discussions about how to expose this feature
> to user-space in a more generic way.
>
> Signed-off-by: Simon Horman <horms@verge.net.au>
>
Of the patches it looks like the only one that really has any issues is
this one and it is mostly due to the sysfs implementation. The others I
would say can be applied and pushed up into the net-next-2.6 tree.
We're currently working on an iproute2 based solution for configuring
VFs and can incorporate this functionality into it at some point in the
future.
Thanks,
Alex
^ permalink raw reply
* Re: [rfc 4/4] igb: expose 82576 bandiwidth allocation
From: Simon Horman @ 2009-11-05 23:30 UTC (permalink / raw)
To: Alexander Duyck
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Arnd Bergmann, Kirsher, Jeffrey T
In-Reply-To: <4AF358F2.9000109@intel.com>
On Thu, Nov 05, 2009 at 03:00:02PM -0800, Alexander Duyck wrote:
> Simon Horman wrote:
> >The 82576 has support for bandwidth allocation to VFs.
> >
> >Contrary to the documentation in the 82576 datasheet v2.41 this
> >appears to work as follows:
> >
> >* The ratio supplied is always proportional to 1Gbit/s,
> > regardless of if the link speed.
> >* The ratio supplied is an upper-bound on bandwidth available
> > to the VF, not a minimun guarantee
> >
> >This patch exposes bandwidth control to userspace through a simple
> >per-device (PF) sysfs file, bandwidth_allocation.
> >
> >* The file contains a whitespace delimited list of values, one per VF.
> >* The first value corresponds to the first VF and so on.
> >* Valid values are integers from 0 to 1000
> >* A value of 0 indicates that bandwidth_allocation is disabled.
> >* Other values indicate the allocated bandwidth, in 1/1000ths of a gigabit/s
> >
> >e.g. The following for a PF with 4 VFs allocates ~20Mbits/ to VF 1,
> > ~100Mbit/s to VF 2, and leave the other 2 VFs with no allocation.
> >
> > echo "20 100 0 0" > /sys/class/net/eth3/device/bandwidth_allocation
> >
> >This interface is intended to allow testing of the hardware feature.
> >There are ongoing discussions about how to expose this feature
> >to user-space in a more generic way.
> >
> >Signed-off-by: Simon Horman <horms@verge.net.au>
> >
>
> Of the patches it looks like the only one that really has any issues
> is this one and it is mostly due to the sysfs implementation. The
> others I would say can be applied and pushed up into the
> net-next-2.6 tree.
Thanks, I suspected as much.
> We're currently working on an iproute2 based solution for
> configuring VFs and can incorporate this functionality into it at
> some point in the future.
Do you have any pointers to discussions relating to that interface.
Do you think it would be worth putting in the sysfs interface in the
mean-time, or would you rather wait?
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply
* Re: [rfc 4/4] igb: expose 82576 bandiwidth allocation
From: Alexander Duyck @ 2009-11-05 23:42 UTC (permalink / raw)
To: Simon Horman
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Kirsher, Jeffrey T, Arnd Bergmann
In-Reply-To: <20091105233034.GA9588@verge.net.au>
Simon Horman wrote:
> On Thu, Nov 05, 2009 at 03:00:02PM -0800, Alexander Duyck wrote:
>> Simon Horman wrote:
>>> The 82576 has support for bandwidth allocation to VFs.
>>>
>>> Contrary to the documentation in the 82576 datasheet v2.41 this
>>> appears to work as follows:
>>>
>>> * The ratio supplied is always proportional to 1Gbit/s,
>>> regardless of if the link speed.
>>> * The ratio supplied is an upper-bound on bandwidth available
>>> to the VF, not a minimun guarantee
>>>
>>> This patch exposes bandwidth control to userspace through a simple
>>> per-device (PF) sysfs file, bandwidth_allocation.
>>>
>>> * The file contains a whitespace delimited list of values, one per VF.
>>> * The first value corresponds to the first VF and so on.
>>> * Valid values are integers from 0 to 1000
>>> * A value of 0 indicates that bandwidth_allocation is disabled.
>>> * Other values indicate the allocated bandwidth, in 1/1000ths of a gigabit/s
>>>
>>> e.g. The following for a PF with 4 VFs allocates ~20Mbits/ to VF 1,
>>> ~100Mbit/s to VF 2, and leave the other 2 VFs with no allocation.
>>>
>>> echo "20 100 0 0" > /sys/class/net/eth3/device/bandwidth_allocation
>>>
>>> This interface is intended to allow testing of the hardware feature.
>>> There are ongoing discussions about how to expose this feature
>>> to user-space in a more generic way.
>>>
>>> Signed-off-by: Simon Horman <horms@verge.net.au>
>>>
>> Of the patches it looks like the only one that really has any issues
>> is this one and it is mostly due to the sysfs implementation. The
>> others I would say can be applied and pushed up into the
>> net-next-2.6 tree.
>
> Thanks, I suspected as much.
>
>> We're currently working on an iproute2 based solution for
>> configuring VFs and can incorporate this functionality into it at
>> some point in the future.
>
> Do you have any pointers to discussions relating to that interface.
> Do you think it would be worth putting in the sysfs interface in the
> mean-time, or would you rather wait?
I'm not the one working on the interface so I don't know much about it
other than the fact it is being worked on. Hopefully we should see
something in regards to that soon though.
If anything it might be of some use to split this up into 2 patches.
One that contains the sysfs bits, and another for enabling the bandwidth
control registers. We won't be able to get the sysfs interface accepted
upstream so there isn't much point in us keeping it around for any other
purpose than testing to verify the registers work as you have described.
Thanks,
Alex
^ permalink raw reply
* Re: Doubt in implementations of mean loss interval at sender side
From: Ivo Calado @ 2009-11-06 0:05 UTC (permalink / raw)
To: Gerrit Renker, dccp, netdev, Ivo Calado
In-Reply-To: <cb00fa210911051603w6fb8de32qd7ebf37ce78408f7@mail.gmail.com>
On Wed, Oct 28, 2009 at 12:33 PM, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> | > This is a good point. Personally, I can not really see an advantage in
> | > storing old data at the sender, as it seems to increase the complexity,
> | > without at the same time introducing a benefit.
> | >
> | > Adding the 'two RTTs old' worth of information at the sender re-introduces
> | > things that were removed already. The old CCID-3 sender used to store
> | > a lot of information about old packets, now it is much leaner and keeps
> | > only the minimum required information.
> |
> | So, how we can solve this? How can we determine if a loss interval is
> | (or not) 2 RTT long in the sender?
> |
> Yes, I also think that this is the core problem.
>
> To be honest, the reply had been receiver-based TFRC in mind but did not
> state the reasons. These are below, which contains also a sketch.
>
> In particular, the 'a lot of information about old packets' mentioned above
> could only be taken out (and with improved performance) since it relied on
> using a receiver-based implementation (in fact the code has always been,
> since the original Lulea code).
>
>
> I) (Minimum) set of data required to be stored at the sender
> ------------------------------------------------------------
> RFC 4342, 6 requires a feedback packet to contain
> (a) Elapsed Time or Timestamp Echo;
> (b) Receive Rate option;
> (c) Loss Intervals Option.
>
> Out of these only (b) is currently supported. (a) used to be supported,
> but it turned out that the elapsed time was in the order of circa 50
> microseconds. Timestamp Echo can only be sent if the sender has sent
> a DCCP timestamp option (RFC 4340, 13.3), so it can not be used for the
> general case.
>
> The sender must be able to handle three scenarios:
>
> (a) receiver sends Loss Event Rate option only
> (b) receiver sends Loss Intervals option only
> (c) receiver sends both Loss Event Rate and Loss Intervals option
>
> The implementation currently does (a) and enforces this by using a
> Mandatory Loss Event Rate option (ccid3_dependencies in net/dccp/feat.c),
> resetting the connection if the peer sender only implements (b).
>
> Case (b) is a pre-stage to case (c), otherwise it can only talk to
> DCCP receivers that implement the Loss Intervals option.
>
> In case (c) (and I think this is in part in your implementation), the
> question is what to trust if the options are mutually inconsistent.
> This is the subject of RFC 4342, 9.2, which suggests to store the sending
> times of (dropped) packets.
>
> Window counter timestamps are problematic here, due to the 'increment by 5'
> rule from RFC 4342, 8.1. Using timestamps raises again the timer-resolution
> question. If using 10usec from RFC 4342, 13.2 as baseline, the sequence
> number will probably also need to be stored since in 10usec multiple
> packets can be transmitted (also when using a lower resolution).
>
> Until here we have got the requirement to store, for each sent packet,
> * its sending time (min. 4 bytes to match RFC 4342, 13.2)
> * its sequence number (u48 or u64)
> Relating to your question at the top of the email, the next item is
> * the RTT estimate at the time the packet was sent, used for
> - verifying the length of the Lossy Part (RFC 4342, 6.1);
> - reducing the sending rate when a Data Dropped option is received, 5.2;
> - determining whether the loss interval was less than or more than 2 RTTs
> (your question, RFC 4828, 4.4).
>
> To sum up, here is whay I think is minimally required to satisfy the union
> of RFC 4340, 4342, 4828, 5348, and 5622:
>
> struct tfrc_tx_packet_info {
> u64 seqno:48,
> is_ect0:1,
> is_data_packet:1,
> is_in_loss_interval:1;
> u32 send_time;
> u32 rtt_estimate;
> struct tfrc_tx_packet_info *next; /* FIFO */
> };
>
> That would be a per-packet storage cost of about 16 bytes, plus the pointer
> (8 bytes on 64-bit architectures). One could avoid the pointer by defining a
> u64 base_seqno;
> and then
> struct tfrc_tx_packet_info[some constant here];
> and then index the array relative to the base_seqno.
>
Yes, I believe that struct is enough too. But how long would be necessary
the struct array to be?
>
> IIb) Further remarks
> --------------------
> At first sight it would seem that storing the RTT also solves the problem
> of inaccurate RTTs used at the receiver. Unfortunately, this is not the
> case. X_recv is sampled over intervals of varying length which may or may
> not equal the RTT. To factor out the effect of window counters, the sender
> would need to store the packet size as well and would need to use rather
> complicated computations - an ugly workaround.
I didn't understand how the packet size would help and what
computations are needed.
>
> One thing I stumbled across while reading your code was the fact that RFC 4342
> leaves it open as to how many Loss Intervals to send: on the one hand it follows
> the suggestion of RFC 5348 to use 1+NINTERVAL=9, but on the other hand it does
> not restrict the number of loss intervals. Also RFC 5622 does not limit the
> number of Loss Intervals / Data Dropped options.
>
> If receiving n > 9 Loss Intervals, what does the sender do with the n-9 older
> intervals? There must be some mechanism to stop these options from growing
> beyond bounds, so it needs to store also which loss intervals have been
> acknowledged, introducing the "Acknowledgment of Acknowledgments"
> problem.
>
In RFC 4342 section 8.6 it says that the limit of loss interval data
to send is 28, and RFC 5622 8.7 says 84 for dropped packets option.
But I don't see why to send so many data in these options.
Yes, the most recent 9 loss intervals are required to be reported,
except if the sender acknowledged previous sent loss intervals, so in
that case only one is required, the open interval.
And we can avoid the "Acknowledgment of Acknowledgments" if we always send
the required 9 loss intervals, I think.
> A second point is how to compute the loss event rate when n > 9. It seems
> that this would mean grinding through all loss intervals using a window
> of 9. If that is the case, the per-packet-computation costs become very
> expensive.
>
RFC 4342 section 8.6 suggests that only 9 loss intervals are required
anyway. And I believe that's enough for the computation of current
mean loss interval. What do you think?
>
> II) Computational part of the implementation
> --------------------------------------------
> If only Loss Intervals alone are used, only these need to be verified
> before being used to alter the sender behaviour.
>
> But when one or more other DCCP options also appear, the verification is
> * intra: make sure each received option is in itself consistent,
> * inter: make sure options are mutually consistent.
>
> The second has a combinatorial effect, i.e. n! verifications for n options.
>
> For n=2 we have Loss Intervals and Dropped Packets: the consistency must
> be in both directions, so we need two stages of verifications.
>
> If Ack Vectors are used in addition to Loss Intervals, then their data
> must also be verified. Here we have up to 6 = 3! testing stages.
>
> It gets more complicated (4! = 24 checks) by also adding Data Dropped
> options, where RFC 4340, 11.7 requires to check them against the Ack
> Vector, and thus ultimately also against the Loss Intervals option.
>
Yes, there's a combinatorial problem in checking the options for
consistence. But, what if we find out that some option doesn't match
against others? What action would be taken?
First, what can cause the receiver to send inconsistent options? A bad
implementation only?
Accordingly to ecn nonce echo sum algorithm, if a receiver is found to
be lying about loss or to be bad implemented, the sender adjusts the
send rate as if loss were perceived. Can we do the same in this
situation? If so, can we skip
checking options between them and only check ecn nonce sum?
If some option is wrong it show more loss (or any worse situation for
the receiver)
or conceals loss. In the first case, I don't believe we need to care,
and in the second, the ecn nonce sum can reveal the bad acting of the
receiver.
>
> III) Closing remarks in favour of receiver-based implementation
> ---------------------------------------------------------------
> Finally, both RFC 4342 and RFC 5622 do not explicitly discard the
> possibility of using a receiver-based implementation. Quoting
> RFC 4342, 3.2: "If it prefers, the sender can also use a loss event
> rate calculated and reported by the receiver."
> Furthermore, the revised TFRC specification points out in section 7
> the advantages that a receiver-based implementation has:
> * it does not mandate reliable delivery of packet loss data;
> * it is robust against the loss of feedback packets;
> * better suited for scalable server design.
>
> Quite likely, if the server does not have to store and validate a mass
> of data, it is also less prone to be toppled by DoS attacks.
>
You're right. But what the RFC's says about it is almost exactly the
opposite, isn't? What can we do about it? I like the receiver-based design,
but I believe that loss intervals are interesting, mostly because of
receiver behavior verification.
> | > As a second point, I still think that a receiver-based CCID-4 implementation
> | > would be the simplest possible starting point. In this light, do you see an
> | > advantage in supplying an RTT estimate from sender to receiver?
> |
> | Yes, better precision. But, at the cost of adding an option
> | undocumented by any RFC's?
> |
> No I wasn't suggesting that. As you rightly point out, the draft has
> expired. It would need to be overhauled (all the references have
> changed, but the problem has not), and I was asking whether returning
> to this has any benefit.
>
> The text is the equivalent of a bug report. RFCs are like software - if no
> one submits bug reports, they become features, until someone has enough of
> such 'features' and writes a new specification.
--
Ivo Augusto Andrade Rocha Calado
MSc. Candidate
Embedded Systems and Pervasive Computing Lab - http://embedded.ufcg.edu.br
Systems and Computing Department - http://www.dsc.ufcg.edu.br
Electrical Engineering and Informatics Center - http://www.ceei.ufcg.edu.br
Federal University of Campina Grande - http://www.ufcg.edu.br
PGP: 0x03422935
Putt's Law:
Technology is dominated by two types of people:
Those who understand what they do not manage.
Those who manage what they do not understand.
^ permalink raw reply
* [PATCH 02/25 v2] mlx4_core: add support for arbitrary bitmap sizes
From: Yevgeny Petrilin @ 2009-11-06 3:08 UTC (permalink / raw)
To: rdreier; +Cc: linux-rdma, netdev, liranl, tziporet, yevgenyp
From: Liran Liss <liranl@mellanox.co.il>
Signed-off-by: Liran Liss <liranl@mellanox.co.il>
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
---
drivers/net/mlx4/alloc.c | 10 ++++++++++
drivers/net/mlx4/mlx4.h | 2 ++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/net/mlx4/alloc.c b/drivers/net/mlx4/alloc.c
index ad95d5f..bc68cc3 100644
--- a/drivers/net/mlx4/alloc.c
+++ b/drivers/net/mlx4/alloc.c
@@ -177,6 +177,16 @@ int mlx4_bitmap_init(struct mlx4_bitmap *bitmap, u32 num, u32 mask,
return 0;
}
+/* Like bitmap_init, but doesn't require 'num' to be a power of 2 or
+ * a non-trivial mask */
+int mlx4_bitmap_init_no_mask(struct mlx4_bitmap *bitmap, u32 num,
+ u32 reserved_bot, u32 reserved_top)
+{
+ u32 num_rounded = roundup_pow_of_two(num);
+ return mlx4_bitmap_init(bitmap, num_rounded, num_rounded - 1,
+ reserved_bot, num_rounded - num + reserved_top);
+}
+
void mlx4_bitmap_cleanup(struct mlx4_bitmap *bitmap)
{
kfree(bitmap->table);
diff --git a/drivers/net/mlx4/mlx4.h b/drivers/net/mlx4/mlx4.h
index bc72d6e..5836c94 100644
--- a/drivers/net/mlx4/mlx4.h
+++ b/drivers/net/mlx4/mlx4.h
@@ -330,6 +330,8 @@ u32 mlx4_bitmap_alloc_range(struct mlx4_bitmap *bitmap, int cnt, int align);
void mlx4_bitmap_free_range(struct mlx4_bitmap *bitmap, u32 obj, int cnt);
int mlx4_bitmap_init(struct mlx4_bitmap *bitmap, u32 num, u32 mask,
u32 reserved_bot, u32 resetrved_top);
+int mlx4_bitmap_init_no_mask(struct mlx4_bitmap *bitmap, u32 num,
+ u32 reserved_bot, u32 reserved_top);
void mlx4_bitmap_cleanup(struct mlx4_bitmap *bitmap);
int mlx4_reset(struct mlx4_dev *dev);
--
1.5.3.7
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox