* Re: [PATCH net-next-2.6] be2net: Fix UDP packet detected status in RX compl
From: David Miller @ 2011-03-15 21:57 UTC (permalink / raw)
To: padmanabh.ratnakar; +Cc: netdev, sathya.perla
In-Reply-To: <fa0d690e-8b0a-4608-be17-d65c22246f37@exht1.ad.emulex.com>
From: Padmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
Date: Tue, 15 Mar 2011 15:59:01 +0530
> Status of UDP packet detection not getting populated in RX completion
> structure. This is required in csum_passed() routine.
>
> Signed-off-by: Padmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Applied, thanks.
^ permalink raw reply
* Re: linux-next: build failure after merge of the net tree
From: David Miller @ 2011-03-15 22:07 UTC (permalink / raw)
To: tglx; +Cc: sfr, bhutchings, netdev, linux-next, linux-kernel, mingo, hpa,
peterz
In-Reply-To: <alpine.LFD.2.00.1103151128070.2787@localhost6.localdomain6>
From: Thomas Gleixner <tglx@linutronix.de>
Date: Tue, 15 Mar 2011 11:29:18 +0100 (CET)
> On Tue, 15 Mar 2011, Stephen Rothwell wrote:
>
>> Hi Dave,
>>
>> On Mon, 14 Mar 2011 21:07:12 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>> >
>> > From: Stephen Rothwell <sfr@canb.auug.org.au>
>> > Date: Tue, 15 Mar 2011 11:30:49 +1100
>> >
>> > > So, if you merge the commit 1fb0ef31f428 ("genirq: Fix affinity notifier
>> > > fallout") from the tip tree, you will get exactly one new commit and will
>> > > fix your tree properly with no adverse effect on anyone else.
>> >
>> > Thomas, how would you like me to do this? Do you want to put that
>> > commit on a branch for me to pull from or should I apply it
>> > directly?
>>
>> That commit is already the head of the irq/numa branch in the tip tree
>> (it is also on the irq/core branch).
>>
>> Please merge that rather than cherry-picking the commit as that will
>> minimise the possibility of conflicts. Pulling the irq/numa branch will
>> get you just that one fixup commit (as you have already merged up to the
>> immediately preceding commit).
>>
>> I assume this makes sense, Thomas? I just did a merge of the actual
>> fixup commit after merging the net tree.
>
> Yes. irq/numa should do the trick.
Great, I'll do that now.
^ permalink raw reply
* Re: [RFC v3 3/6] can: make struct proto const
From: Kurt Van Dijck @ 2011-03-15 22:12 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, Eric Dumazet
In-Reply-To: <4D7FD9ED.1080004-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
On Tue, Mar 15, 2011 at 10:28:13PM +0100, Oliver Hartkopp wrote:
> On 14.03.2011 18:17, Kurt Van Dijck wrote:
> > On Mon, Mar 14, 2011 at 05:42:23PM +0100, Eric Dumazet wrote:
> >> Le lundi 14 mars 2011 à 16:02 +0100, Kurt Van Dijck a écrit :
> >>
> >>> I see your point.
> >>> The reason I modified this was, as described, checkpatch.pl was complaining.
> >>> Anyway, this sequence was protected by a spinlock 'proto_tab_lock'.
> >>> I don't think it was a race.
> >>>
> >>> Did I miss something?
> >>
> >> As soon as proto_tab[proto] = cp; is done, another thread on another cpu
> >> can read the pointer and follow it.
> >>
> >> Hmm, I missed can_create() also uses the spinlock protection, so you're
> >> probably right.
> >>
> >> It seems a bit overkill :(
> >> phonet uses RCU for example.
>
> Hello Eric,
>
> the RCU code in phonet is worth to consider. But loading and removing of
> protocols is far away from being a hot path ... what would be the advantages
> to move to RCU here?
Does RCU avoid a spinlock?
>
> > I'll keep that in mind.
> > Switching CAN protos to RCU is far beyond to goal of this patch :-)
>
> Anyway making the struct proto a const (and set the default defines in the CAN
> protocols) is a nice cleanup. Let's wait for the feedback about the RCU from
> Eric ... then this patch could be put into mainline independently from the
> j1939 protocol.
ack.
Kurt
_______________________________________________
Socketcan-core mailing list
Socketcan-core@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: IPsec tunnel forwarding in net-next-2.6 since 452edd59
From: Eric Dumazet @ 2011-03-15 22:16 UTC (permalink / raw)
To: Michael Smith; +Cc: netdev, David Miller
In-Reply-To: <4D7FB054.2090902@cbnco.com>
Le mardi 15 mars 2011 à 14:30 -0400, Michael Smith a écrit :
> Hi,
>
> I'm able to ping across a tunnel to a peer running net-next-2.6, but
> only to an interface on the peer; trying to ping a host behind the peer
> fails. The incoming packet shows up in encrypted and decrypted form in
> tcpdump, but it's not forwarded. None of the XFRM error counters are
> incremented; the packets just silently fail to be forwarded.
>
> There are no iptables rules and net.ipv4.ip_forward=1. The same config
> works on 2.6.38-rc8. git bisect pointed me to commit 452edd59 from March 2:
>
> xfrm: Return dst directly from xfrm_lookup()
>
> Instead of on the stack.
>
>
> ip xfrm policy:
>
> src 192.168.136.0/24 dst 192.168.137.0/24
> dir out priority 2344 ptype main
> tmpl src 1.1.1.136 dst 1.1.1.137
> proto esp reqid 16385 mode tunnel
>
> src 192.168.137.0/24 dst 192.168.136.0/24
> dir fwd priority 2344 ptype main
> tmpl src 1.1.1.137 dst 1.1.1.136
> proto esp reqid 16385 mode tunnel
>
> src 192.168.137.0/24 dst 192.168.136.0/24
> dir in priority 2344 ptype main
> tmpl src 1.1.1.137 dst 1.1.1.136
> proto esp reqid 16385 mode tunnel
>
> net-next-2.6 host is at 1.1.1.136 and 192.168.136.1. 2.6.35.10 host is
> at 1.1.1.137 and 192.168.137.1. From that host:
>
> ping -I 192.168.137.1 192.168.136.1 -> success
> ping -I 192.168.137.1 192.168.136.2 -> silent failure
>
> Thanks,
Thanks for this excellent bug report !
Could you try following patch ?
[PATCH] xfrm: fix __xfrm_route_forward()
This function should return 0 in case of error, 1 if OK
commit 452edd598f60522 (xfrm: Return dst directly from xfrm_lookup())
got it wrong.
Reported-and-bisected-by: Michael Smith <msmith@cbnco.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 1ba0258..027e3c6 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -2175,7 +2175,7 @@ int __xfrm_route_forward(struct sk_buff *skb, unsigned short family)
struct net *net = dev_net(skb->dev);
struct flowi fl;
struct dst_entry *dst;
- int res = 0;
+ int res = 1;
if (xfrm_decode_session(skb, &fl, family) < 0) {
XFRM_INC_STATS(net, LINUX_MIB_XFRMFWDHDRERROR);
@@ -2186,7 +2186,7 @@ int __xfrm_route_forward(struct sk_buff *skb, unsigned short family)
dst = xfrm_lookup(net, skb_dst(skb), &fl, NULL, 0);
if (IS_ERR(dst)) {
- res = 1;
+ res = 0;
dst = NULL;
}
skb_dst_set(skb, dst);
^ permalink raw reply related
* Re: [RFC v3 3/6] can: make struct proto const
From: Eric Dumazet @ 2011-03-15 22:19 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: Kurt Van Dijck, socketcan-core, netdev
In-Reply-To: <4D7FD9ED.1080004@hartkopp.net>
Le mardi 15 mars 2011 à 22:28 +0100, Oliver Hartkopp a écrit :
> Hello Eric,
>
> the RCU code in phonet is worth to consider. But loading and removing of
> protocols is far away from being a hot path ... what would be the advantages
> to move to RCU here?
>
can_create() could avoid taking the spinlock.
I have no idea if its a critical path, I guess not.
^ permalink raw reply
* Re: IPsec tunnel forwarding in net-next-2.6 since 452edd59
From: David Miller @ 2011-03-15 22:28 UTC (permalink / raw)
To: eric.dumazet; +Cc: msmith, netdev
In-Reply-To: <1300227411.2565.7.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 15 Mar 2011 23:16:51 +0100
> Could you try following patch ?
>
> [PATCH] xfrm: fix __xfrm_route_forward()
>
> This function should return 0 in case of error, 1 if OK
> commit 452edd598f60522 (xfrm: Return dst directly from xfrm_lookup())
> got it wrong.
>
> Reported-and-bisected-by: Michael Smith <msmith@cbnco.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Thanks so much for fixing this Eric, sheesh you are so awesome that
you don't even give me enough time to fix my own bugs. :-))))
Applied, and indeed thanks to Michael for the excellent report.
^ permalink raw reply
* Re: IPsec tunnel forwarding in net-next-2.6 since 452edd59
From: Eric Dumazet @ 2011-03-15 22:31 UTC (permalink / raw)
To: David Miller; +Cc: msmith, netdev
In-Reply-To: <20110315.152825.193708028.davem@davemloft.net>
Le mardi 15 mars 2011 à 15:28 -0700, David Miller a écrit :
> Thanks so much for fixing this Eric, sheesh you are so awesome that
> you don't even give me enough time to fix my own bugs. :-))))
>
Well, I know you must be pretty busy now linux-2.6.38 is released ;)
> Applied, and indeed thanks to Michael for the excellent report.
>
^ permalink raw reply
* Re: [Bloat] shaper team forming up
From: David Miller @ 2011-03-15 22:51 UTC (permalink / raw)
To: eric.dumazet; +Cc: chromatix99, d, netdev
In-Reply-To: <1300164166.2649.70.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 15 Mar 2011 05:42:46 +0100
> Le lundi 14 mars 2011 à 21:24 +0100, Eric Dumazet a écrit :
>
> David, it seems ip_tos2prio is wrong on its 2nd entry :
Indeed, and in context, this is simply a thinko which has survived since
ECN support first got added to the tree, here's the relevant hunk:
--------------------
@@ -152,23 +152,29 @@ struct dst_ops ipv4_dst_ops =
sizeof(struct rtable),
};
+#ifdef CONFIG_INET_ECN
+#define ECN_OR_COST(class) TC_PRIO_##class
+#else
+#define ECN_OR_COST(class) TC_PRIO_FILLER
+#endif
+
__u8 ip_tos2prio[16] = {
TC_PRIO_BESTEFFORT,
- TC_PRIO_FILLER,
+ ECN_OR_COST(FILLER),
TC_PRIO_BESTEFFORT,
- TC_PRIO_FILLER,
+ ECN_OR_COST(BESTEFFORT),
TC_PRIO_BULK,
- TC_PRIO_FILLER,
+ ECN_OR_COST(BULK),
TC_PRIO_BULK,
- TC_PRIO_FILLER,
+ ECN_OR_COST(BULK),
TC_PRIO_INTERACTIVE,
- TC_PRIO_FILLER,
+ ECN_OR_COST(INTERACTIVE),
TC_PRIO_INTERACTIVE,
- TC_PRIO_FILLER,
+ ECN_OR_COST(INTERACTIVE),
TC_PRIO_INTERACTIVE_BULK,
- TC_PRIO_FILLER,
+ ECN_OR_COST(INTERACTIVE_BULK),
TC_PRIO_INTERACTIVE_BULK,
- TC_PRIO_FILLER
+ ECN_OR_COST(INTERACTIVE_BULK)
};
^ permalink raw reply
* Re: IPsec tunnel forwarding in net-next-2.6 since 452edd59
From: Michael Smith @ 2011-03-15 22:51 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, David Miller
In-Reply-To: <1300227411.2565.7.camel@edumazet-laptop>
On Tue, 15 Mar 2011, Eric Dumazet wrote:
> Could you try following patch ?
>
> [PATCH] xfrm: fix __xfrm_route_forward()
>
> This function should return 0 in case of error, 1 if OK
> commit 452edd598f60522 (xfrm: Return dst directly from xfrm_lookup())
> got it wrong.
That does the trick, thanks! Nice catch.
Mike
^ permalink raw reply
* Re: [Bloat] shaper team forming up
From: David Miller @ 2011-03-15 22:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: chromatix99, d, netdev
In-Reply-To: <1300164166.2649.70.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 15 Mar 2011 05:42:46 +0100
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 6ed6603..fabfe81 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -171,7 +171,7 @@ static struct dst_ops ipv4_dst_ops = {
>
> const __u8 ip_tos2prio[16] = {
> TC_PRIO_BESTEFFORT,
> - ECN_OR_COST(FILLER),
> + ECN_OR_COST(BESTEFFORT),
> TC_PRIO_BESTEFFORT,
> ECN_OR_COST(BESTEFFORT),
> TC_PRIO_BULK,
>
>
Eric can you please formally submit this fix? I'd like to apply it soon.
Thanks.
^ permalink raw reply
* net-next-2.6 status...
From: David Miller @ 2011-03-15 23:01 UTC (permalink / raw)
To: netdev
Cc: linux-wireless, netfilter-devel, eric.dumazet, jpirko, linville,
kaber
Please do not submit feature patches until the merge window is over and
Linus releases 2.6.39-rc1, thank you.
Bug fixes are, of course, still ok.
I have merged all of the stragglers from net-2.6 that didn't make it
into 2.6.38 into net-next-2.6, and also just about everything that
is relevant from patchwork.
Jiri, I know there is your patch set there, but I think you and Changli
still need to go back and forth one more time wrt. orig_dev semantics.
Since you have been posting this patch set for some time I'm still
willing to apply it for this merge window, but please make haste and
work out the remaining discussion. Thank you.
Eric, I'd like to have the ECN one-liner in the tree soon.
John and Patrick, I assume that after today's pulls I am completely
up to date with everything, feature wise, that will go into the merge
window for wireless and netfilter.
Thanks.
^ permalink raw reply
* Re: [Bloat] shaper team forming up
From: Eric Dumazet @ 2011-03-15 23:00 UTC (permalink / raw)
To: David Miller; +Cc: chromatix99, d, netdev
In-Reply-To: <20110315.155305.71104836.davem@davemloft.net>
Le mardi 15 mars 2011 à 15:53 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 15 Mar 2011 05:42:46 +0100
>
> > diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> > index 6ed6603..fabfe81 100644
> > --- a/net/ipv4/route.c
> > +++ b/net/ipv4/route.c
> > @@ -171,7 +171,7 @@ static struct dst_ops ipv4_dst_ops = {
> >
> > const __u8 ip_tos2prio[16] = {
> > TC_PRIO_BESTEFFORT,
> > - ECN_OR_COST(FILLER),
> > + ECN_OR_COST(BESTEFFORT),
> > TC_PRIO_BESTEFFORT,
> > ECN_OR_COST(BESTEFFORT),
> > TC_PRIO_BULK,
> >
> >
>
> Eric can you please formally submit this fix? I'd like to apply it soon.
>
> Thanks.
Sure, I can do this right now, but I want to fully credit Dan Siemon on
this one, as the author of the patch.
^ permalink raw reply
* Re: [PATCH] ipv4: Cache source address in nexthop entries.
From: David Miller @ 2011-03-15 23:02 UTC (permalink / raw)
To: ja; +Cc: netdev
In-Reply-To: <alpine.LFD.2.00.1103151135110.1729@ja.ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Tue, 15 Mar 2011 12:00:33 +0200 (EET)
> I see another problem with nh_saddr. fib_info
> is reused when NHs and some parameters are equal but the
> scope is not part of the fib_info and it is wrong to cache
> route scope in NH or even in fib_info. The problem is
> that we can expose in nh_saddr addresses with wrong
> scope for the route. It happens when two routes with
> different route scope reuse same fib_info.
>
> First thought is that the field fa_scope can be
> moved into fib_scope in struct fib_info, not to use
> nh_cfg_scope. Then fib_find_info can differentiate the
> entries by fib_scope. It means, fib_info will not be reused
> if fib_scope is different. For FIB_RES_PREFSRC I assume we
> can access fib_info from nh->nh_parent safely when
> refreshing nh_saddr.
>
> Here is a script that demonstrates the wrong
> exposing:
Thanks for all of your feedback Julian, I will look into
this very soon.
^ permalink raw reply
* Re: [PATCH] Disable rp_filter for IPsec packets
From: Michael Smith @ 2011-03-15 23:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110314.152704.98879085.davem@davemloft.net>
On Mon, 14 Mar 2011, David Miller wrote:
> > David Miller wrote:
> >
> >> Existing arguments might be large enough to carry more than one piece
> >> of information :-)
> >
> > If it's encoded into another argument, would there be more overhead
> > from bit-shifting it out than you'd save by losing an argument?
>
> It sure will if it's the different between the argument being passed
> in a register vs. on the stack.
I have a patch to replace u32 mark with an sk_buff. The mark is in the
sk_buff already, and so is the secpath field I need. Would that be
acceptable? I can hold off until the merge window is over.
-extern int fib_validate_source(__be32 src, __be32 dst, u8 tos, int oif,
- struct net_device *dev, __be32 *spec_dst,
- u32 *itag, u32 mark);
+extern int fib_validate_source(struct sk_buff *skb, __be32 src, __be32 dst,
+ u8 tos, int oif, struct net_device *dev,
+ __be32 *spec_dst, u32 *itag);
(dev is also usually the same as skb->dev, but not always...)
Mike
^ permalink raw reply
* Re: [PATCH] Disable rp_filter for IPsec packets
From: David Miller @ 2011-03-15 23:35 UTC (permalink / raw)
To: msmith; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.1103151913340.28997@juice.ott.cti.com>
From: Michael Smith <msmith@cbnco.com>
Date: Tue, 15 Mar 2011 19:21:29 -0400 (EDT)
> On Mon, 14 Mar 2011, David Miller wrote:
>
>> > David Miller wrote:
>> >
>> >> Existing arguments might be large enough to carry more than one piece
>> >> of information :-)
>> >
>> > If it's encoded into another argument, would there be more overhead
>> > from bit-shifting it out than you'd save by losing an argument?
>>
>> It sure will if it's the different between the argument being passed
>> in a register vs. on the stack.
>
> I have a patch to replace u32 mark with an sk_buff. The mark is in the
> sk_buff already, and so is the secpath field I need. Would that be
> acceptable? I can hold off until the merge window is over.
Sounds good, and yes please wait until after the merge window.
^ permalink raw reply
* [PATCH] net_sched: fix ip_tos2prio
From: Eric Dumazet @ 2011-03-15 23:56 UTC (permalink / raw)
To: David Miller; +Cc: chromatix99, d, netdev, Dan Siemon
In-Reply-To: <20110315.155305.71104836.davem@davemloft.net>
From: Dan Siemon <dan@coverfire.com>
ECN support incorrectly maps ECN BESTEFFORT packets to TC_PRIO_FILLER
(1) instead of TC_PRIO_BESTEFFORT (0)
This means ECN enabled flows are placed in pfifo_fast/prio low priority
band, giving ECN enabled flows [ECT(0) and CE codepoints] higher drop
probabilities.
This is rather unfortunate, given we would like ECN being more widely
used.
Ref : http://www.coverfire.com/archives/2011/03/13/pfifo_fast-and-ecn/
Signed-off-by: Dan Siemon <dan@coverfire.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Dave Täht <d@taht.net>
Cc: Jonathan Morton <chromatix99@gmail.com>
---
Note: I left TC_PRIO_FILLER definition, this can be removed later.
net/ipv4/route.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 209989c..870b518 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -204,7 +204,7 @@ static struct dst_ops ipv4_dst_ops = {
const __u8 ip_tos2prio[16] = {
TC_PRIO_BESTEFFORT,
- ECN_OR_COST(FILLER),
+ ECN_OR_COST(BESTEFFORT),
TC_PRIO_BESTEFFORT,
ECN_OR_COST(BESTEFFORT),
TC_PRIO_BULK,
^ permalink raw reply related
* pull request: wireless-2.6 2011-03-15
From: John W. Linville @ 2011-03-16 0:12 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Dave,
I nearly forgot this one! It is a really simple patch to enable the use
of some (so far still unreleased) firmware for the iwl1000 hardware.
Please pull for 2.6.39-rc1, so that users will be able to use the
new firmware when it is generally available!
John
---
The following changes since commit 84c0c6933cb0303fa006992a6659c2b46de4eb17:
smsc911x: Fix build error when SMSC_TRACE() used (2011-03-15 14:52:48 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Fry, Donald H (1):
iwlagn: Support new 1000 microcode.
drivers/net/wireless/iwlwifi/iwl-1000.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-1000.c b/drivers/net/wireless/iwlwifi/iwl-1000.c
index ba78bc8..507cab4 100644
--- a/drivers/net/wireless/iwlwifi/iwl-1000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-1000.c
@@ -49,7 +49,7 @@
#include "iwl-agn-debugfs.h"
/* Highest firmware API version supported */
-#define IWL1000_UCODE_API_MAX 3
+#define IWL1000_UCODE_API_MAX 5
#define IWL100_UCODE_API_MAX 5
/* Lowest firmware API version supported */
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: net-next-2.6 status...
From: John W. Linville @ 2011-03-16 0:13 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
eric.dumazet-u79uwXL29TY76Z2rM5mHXA,
jpirko-H+wXaHxf7aLQT0dZR+AlfA, kaber-dcUjhNyLwpNeoWH0uzbU5w
In-Reply-To: <20110315.160124.104058374.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Tue, Mar 15, 2011 at 04:01:24PM -0700, David Miller wrote:
> John and Patrick, I assume that after today's pulls I am completely
> up to date with everything, feature wise, that will go into the merge
> window for wireless and netfilter.
Just sent a pull request for wireless-2.6 to cover a one-liner to
enable some new firmware for iwlagn -- I nearly forgot!
Thanks,
John
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] tcp: avoid cwnd moderation in undo
From: Yuchung Cheng @ 2011-03-16 0:34 UTC (permalink / raw)
To: Carsten Wolff; +Cc: David Miller, Ilpo Jarvinen, Nandita Dukkipati, netdev
In-Reply-To: <201103151107.35379.carsten@wolffcarsten.de>
On Tue, Mar 15, 2011 at 3:07 AM, Carsten Wolff <carsten@wolffcarsten.de> wrote:
>
> Hi,
>
> On Monday 14 March 2011, Yuchung Cheng wrote:
> > On Mon, Mar 14, 2011 at 3:06 AM, Carsten Wolff <carsten@wolffcarsten.de>
> wrote:
> > In the presence of reordering, cwnd is already moderated in Disorder
> > state before
> > entering the (false) recovery.
>
> Sure, cwnd moderation to in_flight + 1 segment is applied in disorder state,
it's in_flight + 3 usually. the moderation first happens
tcp_try_to_open() instead of tcp_cwnd_down()
>
> because this is implementing a form of extended limited transmit.
> Nevertheless, after a reordering event that caused a spurious fast retransmit,
> there can be an undo of congestion state changes (either after recovery or
> interrupting recovery, depending on the options enabled in the connection). I
> just wanted to point out, that the moderation step happening upon an undo may
> allow a larger burst, if a previous reordering event was detected and caused
> tp->reordering to be increased.
Your point is that cwnd should be moderated on reordering (in undo or
other events). Point taken.
My point is that cwnd does not need to be moderated on false
recoveries. Do you agree?
To implement your design, tcp_update_reordering should do
tcp_cwnd_moderation().
To implement my point, the moderations should be avoided in undo operations.
The two aren't in conflict. But there are cases that have both undo
and reordering.
Are we on the same page?
>
> > > More importantly, the prior ssthresh is restored and not affected by
> > > moderation. This means, if moderation reduces cwnd to a small value, then
> > > cwnd < ssthresh and TCP will quickly slow-start back to the previous
> > > state, without sending a big burst of segments.
>
> This is actually the more important point, because it means that the
> moderation does not negate the effects of the undo operation, as suggested by
> your patch-description.
It's a double-edge sword. Why slow-start if there is no real loss? It
hurts short
request-response type traffic performance badly b/c each undo makes cwnd = 3.
>
> False fast retransmits are mostly caused by reordering, spurious RTOs can also
> be caused by delay variations that do not exhibit reordering. Your patch
> touches all cases of spurious events. Anyway, I just mentioned reordering,
> because it is the event in which Linux already allows larger bursts of size
> tp->reordering in the moderation function (i.e. tp->reordering might be
> increased). It's also not important to me if the undo is happening duringor
> after recovery, the important question is, if burst protection in general is
> an important goal, or not (and I think it's there for a reason).
I am hoping my previous explanation make sense to you (these two points are
not in conflict).
^ permalink raw reply
* Re: net-next-2.6 status...
From: Jeff Kirsher @ 2011-03-16 0:36 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-wireless, netfilter-devel, eric.dumazet, jpirko,
linville, kaber
In-Reply-To: <20110315.160124.104058374.davem@davemloft.net>
On Tue, Mar 15, 2011 at 16:01, David Miller <davem@davemloft.net> wrote:
>
> Please do not submit feature patches until the merge window is over and
> Linus releases 2.6.39-rc1, thank you.
>
> Bug fixes are, of course, still ok.
>
Understood, thanks Dave.
--
Cheers,
Jeff
^ permalink raw reply
* Re: [PATCH] net_sched: fix ip_tos2prio
From: David Miller @ 2011-03-16 1:54 UTC (permalink / raw)
To: eric.dumazet; +Cc: chromatix99, d, netdev, dan
In-Reply-To: <1300233367.2565.133.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 16 Mar 2011 00:56:07 +0100
> From: Dan Siemon <dan@coverfire.com>
>
> ECN support incorrectly maps ECN BESTEFFORT packets to TC_PRIO_FILLER
> (1) instead of TC_PRIO_BESTEFFORT (0)
>
> This means ECN enabled flows are placed in pfifo_fast/prio low priority
> band, giving ECN enabled flows [ECT(0) and CE codepoints] higher drop
> probabilities.
>
> This is rather unfortunate, given we would like ECN being more widely
> used.
>
> Ref : http://www.coverfire.com/archives/2011/03/13/pfifo_fast-and-ecn/
>
> Signed-off-by: Dan Siemon <dan@coverfire.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Dave Täht <d@taht.net>
> Cc: Jonathan Morton <chromatix99@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: pull request: wireless-2.6 2011-03-15
From: David Miller @ 2011-03-16 1:55 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110316001234.GA28663-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Tue, 15 Mar 2011 20:12:34 -0400
> I nearly forgot this one! It is a really simple patch to enable the use
> of some (so far still unreleased) firmware for the iwl1000 hardware.
>
> Please pull for 2.6.39-rc1, so that users will be able to use the
> new firmware when it is generally available!
Ok, pulled, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/3] bonding: various fixes
From: David Miller @ 2011-03-16 2:29 UTC (permalink / raw)
To: andy; +Cc: kernel, netdev, fubar
In-Reply-To: <20110314210435.GZ11864@gospo.rdu.redhat.com>
From: Andy Gospodarek <andy@greyhouse.net>
Date: Mon, 14 Mar 2011 17:04:35 -0400
> On Mon, Mar 14, 2011 at 09:22:03AM -0700, Phil Oester wrote:
>> A few collected fixes to bonding. Patches are against net-next,
>> but should apply fine to 38-rc.
>>
>> Phil
>>
>>
>> bond_main.c | 15 +++++++++++----
>> bond_sysfs.c | 5 ++++-
>> 2 files changed, 15 insertions(+), 5 deletions(-)
>
> All in the series look good. Thanks for posting the queue cleanup,
> Phil.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
All applied, thanks.
^ permalink raw reply
* Re: [PATCH v6] xen network backend driver
From: David Miller @ 2011-03-16 2:38 UTC (permalink / raw)
To: Ian.Campbell
Cc: netdev, xen-devel, jeremy, herbert, konrad.wilk, romieu,
bhutchings, shemminger, mirqus, eric.dumazet
In-Reply-To: <1300183578.17339.2239.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 15 Mar 2011 10:06:18 +0000
> netback is the host side counterpart to the frontend driver in
> drivers/net/xen-netfront.c. The PV protocol is also implemented by
> frontend drivers in other OSes too, such as the BSDs and even Windows.
>
> The patch is based on the driver from the xen.git pvops kernel tree but
> has been put through the checkpatch.pl wringer plus several manual
> cleanup passes and review iterations. The driver has been moved from
> drivers/xen/netback to drivers/net/xen-netback.
>
> One major change from xen.git is that the guest transmit path (i.e. what
> looks like receive to netback) has been significantly reworked to remove
> the dependency on the out of tree PageForeign page flag (a core kernel
> patch which enables a per page destructor callback on the final
> put_page). This page flag was used in order to implement a grant map
> based transmit path (where guest pages are mapped directly into SKB
> frags). Instead this version of netback uses grant copy operations into
> regular memory belonging to the backend domain. Reinstating the grant
> map functionality is something which I would like to revisit in the
> future.
>
> Note that this driver depends on 2e820f58f7ad "xen/irq: implement
> bind_interdomain_evtchn_to_irqhandler for backend drivers" which is in
> linux next via the "xen-two" tree and is intended for the 2.6.39 merge
> window:
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/backends
> this branch has only that single commit since 2.6.38-rc2 and is safe for
> cross merging into the net branch.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
Ok, I merged that xen commit into my tree and then added this
driver.
Thanks.
^ permalink raw reply
* No iproute2 for 2.6.38
From: Stephen Hemminger @ 2011-03-16 2:55 UTC (permalink / raw)
To: linux-kernel, netdev
I am not going to bother releasing for 2.6.38 the only changes
were later reverted.
---
Roopa Prabhu (1):
iproute2: add VF_PORT support
Stephen Hemminger (3):
Update to lasest kernel headers
Revert "iproute2: add VF_PORT support"
v2.6.38
^ 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