* Re: [PATCH 2/8] macb: detect hclk presence from platform data
From: Jamie Iles @ 2011-03-11 13:08 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Jamie Iles, netdev, linux-arm-kernel, nicolas.ferre
In-Reply-To: <20110311124757.GK9351@game.jcrosoft.org>
On Fri, Mar 11, 2011 at 01:47:57PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 08:54 Fri 11 Mar , Jamie Iles wrote:
> > On Fri, Mar 11, 2011 at 02:44:00AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > On 10:10 Thu 10 Mar , Jamie Iles wrote:
> > > > +#ifdef CONFIG_ARCH_AT91
> > > > +#define PCLK_NAME "macb_clk"
> > > > +#else /* CONFIG_ARCH_AT91 */
> > > > +#define PCLK_NAME "pclk"
> > > > +#endif
> > >
> > > we need change the clock name and avoid the ifdef
> > > so this will be generic
> > >
> > > nb I work on the switch to clkdev currently for avr32 and at91
> >
> > This should be gone now. Russell made the suggestion to have a fake clk
> > for hclk on AT91 so I think I've solved that now. There's an updated
> > patch in my reply to Russell's message but essentially I'm using
> > at91_clock_associate() to turn "macb_pclk" into "hclk" and "pclk". Does
> > this seem reasonable?
> please do not use at91_clock_associate as I'm going to remove it as use static
> clock as done on shmobile as example
> so if it's a fake clock please as ochi_clk on 9g45
Ok, that's fine. How about for the "macb_plk" though, won't that need
an at91_clock_associate() or is it OK to rename all of the macb_clk
definitions to have be called "pclk"?
Jamie
^ permalink raw reply
* Re: [PATCH 8/8] macb: support data bus widths > 32 bits
From: Jamie Iles @ 2011-03-11 13:15 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Jamie Iles, netdev, linux-arm-kernel, nicolas.ferre
In-Reply-To: <20110311125523.GN9351@game.jcrosoft.org>
On Fri, Mar 11, 2011 at 01:55:23PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 10:10 Thu 10 Mar , Jamie Iles wrote:
> > Some GEM implementations may support data bus widths up to 128 bits.
> > Allow the platform data to specify the data bus width and let the driver
> > program it up.
> >
> can we detect it?
Well, the first design configuration register will tell you what the
maximum data bus width is so we could probably always go with that. I
can't think of a good reason why you wouldn't want to do that.
Jamie
^ permalink raw reply
* Re: [PATCH 4/8] macb: initial support for Cadence GEM
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-03-11 13:14 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, linux-arm-kernel, nicolas.ferre
In-Reply-To: <1299751843-9743-5-git-send-email-jamie@jamieiles.com>
On 10:10 Thu 10 Mar , Jamie Iles wrote:
> The Cadence GEM is based on the MACB Ethernet controller but has a few
> small changes with regards to register and bitfield placement. This
> patch adds a new platform driver for gem which sets allows the driver to
> tell at runtime whether it is targetting a GEM device.
>
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
could we avoid all this if else everywhere?
Best Regards,
J.
^ permalink raw reply
* Re: [PATCH 1/8] macb: unify at91 and avr32 platform data
From: Jamie Iles @ 2011-03-11 13:25 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Jamie Iles, Nicolas Ferre, netdev, linux-arm-kernel
In-Reply-To: <20110311125246.GL9351@game.jcrosoft.org>
On Fri, Mar 11, 2011 at 01:52:46PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 08:56 Fri 11 Mar , Jamie Iles wrote:
> > On Fri, Mar 11, 2011 at 02:41:40AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > keep as we need to remove the #ifdef AT91 to cpu_is
> > >
> > > I've patch for this
> >
> > Is this for the user IO register where the value written is conditional
> > on both RMII/MII and arch type?
> yes for
>
> #if defined(CONFIG_ARCH_AT91)
> macb_writel(bp, USRIO, (MACB_BIT(RMII) | MACB_BIT(CLKEN)));
> #else
> macb_writel(bp, USRIO, 0);
> #endif
> else
> #if defined(CONFIG_ARCH_AT91)
> macb_writel(bp, USRIO, MACB_BIT(CLKEN));
> #else
> macb_writel(bp, USRIO, MACB_BIT(MII));
> #endif
Ok, but what about non-AT91/AVR32 systems? They may not have a
mach/cpu.h and won't have cpu_is_foo() for the platforms the driver is
interested in.
Could we supply these values in the platform data so the driver doesn't
need to do any cpu_is_ magic?
Jamie
^ permalink raw reply
* Re: [PATCH 4/8] macb: initial support for Cadence GEM
From: Jamie Iles @ 2011-03-11 13:30 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Jamie Iles, netdev, linux-arm-kernel, nicolas.ferre
In-Reply-To: <20110311131415.GO9351@game.jcrosoft.org>
On Fri, Mar 11, 2011 at 02:14:15PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 10:10 Thu 10 Mar , Jamie Iles wrote:
> > The Cadence GEM is based on the MACB Ethernet controller but has a few
> > small changes with regards to register and bitfield placement. This
> > patch adds a new platform driver for gem which sets allows the driver to
> > tell at runtime whether it is targetting a GEM device.
> >
> > Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> could we avoid all this if else everywhere?
I can't really see any other way to do this, but you're right it isn't
particularly nice. Having said that, it is only in the initialization
code so there shouldn't be any real performance impact.
I'm open to ideas though!
Jamie
^ permalink raw reply
* Re: [PATCH 4/8] macb: initial support for Cadence GEM
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-03-11 13:34 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, linux-arm-kernel, nicolas.ferre
In-Reply-To: <20110311133016.GF7357@pulham.picochip.com>
On 13:30 Fri 11 Mar , Jamie Iles wrote:
> On Fri, Mar 11, 2011 at 02:14:15PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 10:10 Thu 10 Mar , Jamie Iles wrote:
> > > The Cadence GEM is based on the MACB Ethernet controller but has a few
> > > small changes with regards to register and bitfield placement. This
> > > patch adds a new platform driver for gem which sets allows the driver to
> > > tell at runtime whether it is targetting a GEM device.
> > >
> > > Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> > could we avoid all this if else everywhere?
>
> I can't really see any other way to do this, but you're right it isn't
> particularly nice. Having said that, it is only in the initialization
> code so there shouldn't be any real performance impact.
>
> I'm open to ideas though!
use macro or inline at least
Best Regards,
J.
^ permalink raw reply
* Re: [PATCH 1/8] macb: unify at91 and avr32 platform data
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-03-11 13:37 UTC (permalink / raw)
To: Jamie Iles; +Cc: Nicolas Ferre, netdev, linux-arm-kernel
In-Reply-To: <20110311132536.GE7357@pulham.picochip.com>
On 13:25 Fri 11 Mar , Jamie Iles wrote:
> On Fri, Mar 11, 2011 at 01:52:46PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 08:56 Fri 11 Mar , Jamie Iles wrote:
> > > On Fri, Mar 11, 2011 at 02:41:40AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > keep as we need to remove the #ifdef AT91 to cpu_is
> > > >
> > > > I've patch for this
> > >
> > > Is this for the user IO register where the value written is conditional
> > > on both RMII/MII and arch type?
> > yes for
> >
> > #if defined(CONFIG_ARCH_AT91)
> > macb_writel(bp, USRIO, (MACB_BIT(RMII) | MACB_BIT(CLKEN)));
> > #else
> > macb_writel(bp, USRIO, 0);
> > #endif
> > else
> > #if defined(CONFIG_ARCH_AT91)
> > macb_writel(bp, USRIO, MACB_BIT(CLKEN));
> > #else
> > macb_writel(bp, USRIO, MACB_BIT(MII));
> > #endif
>
> Ok, but what about non-AT91/AVR32 systems? They may not have a
> mach/cpu.h and won't have cpu_is_foo() for the platforms the driver is
> interested in.
>
> Could we supply these values in the platform data so the driver doesn't
> need to do any cpu_is_ magic?
for other arch you can but at91 I prefer to avoid this copy and paste in every
soc
Best Regards,
J.
^ permalink raw reply
* Re: [PATCH 2/8] macb: detect hclk presence from platform data
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-03-11 13:39 UTC (permalink / raw)
To: Jamie Iles; +Cc: netdev, linux-arm-kernel, nicolas.ferre
In-Reply-To: <20110311130826.GB7357@pulham.picochip.com>
On 13:08 Fri 11 Mar , Jamie Iles wrote:
> On Fri, Mar 11, 2011 at 01:47:57PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 08:54 Fri 11 Mar , Jamie Iles wrote:
> > > On Fri, Mar 11, 2011 at 02:44:00AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > On 10:10 Thu 10 Mar , Jamie Iles wrote:
> > > > > +#ifdef CONFIG_ARCH_AT91
> > > > > +#define PCLK_NAME "macb_clk"
> > > > > +#else /* CONFIG_ARCH_AT91 */
> > > > > +#define PCLK_NAME "pclk"
> > > > > +#endif
> > > >
> > > > we need change the clock name and avoid the ifdef
> > > > so this will be generic
> > > >
> > > > nb I work on the switch to clkdev currently for avr32 and at91
> > >
> > > This should be gone now. Russell made the suggestion to have a fake clk
> > > for hclk on AT91 so I think I've solved that now. There's an updated
> > > patch in my reply to Russell's message but essentially I'm using
> > > at91_clock_associate() to turn "macb_pclk" into "hclk" and "pclk". Does
> > > this seem reasonable?
> > please do not use at91_clock_associate as I'm going to remove it as use static
> > clock as done on shmobile as example
> > so if it's a fake clock please as ochi_clk on 9g45
>
> Ok, that's fine. How about for the "macb_plk" though, won't that need
> an at91_clock_associate() or is it OK to rename all of the macb_clk
> definitions to have be called "pclk"?
Personnaly I prefer macb_clk but if Nico prefer pclk it's fine
Best Regards,
J.
^ permalink raw reply
* Re: [PATCH 1/8] macb: unify at91 and avr32 platform data
From: Jamie Iles @ 2011-03-11 13:53 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Jamie Iles, Nicolas Ferre, netdev, linux-arm-kernel
In-Reply-To: <20110311133713.GQ9351@game.jcrosoft.org>
On Fri, Mar 11, 2011 at 02:37:13PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 13:25 Fri 11 Mar , Jamie Iles wrote:
> > On Fri, Mar 11, 2011 at 01:52:46PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > On 08:56 Fri 11 Mar , Jamie Iles wrote:
> > > > On Fri, Mar 11, 2011 at 02:41:40AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > > keep as we need to remove the #ifdef AT91 to cpu_is
> > > > >
> > > > > I've patch for this
> > > >
> > > > Is this for the user IO register where the value written is conditional
> > > > on both RMII/MII and arch type?
> > > yes for
> > >
> > > #if defined(CONFIG_ARCH_AT91)
> > > macb_writel(bp, USRIO, (MACB_BIT(RMII) | MACB_BIT(CLKEN)));
> > > #else
> > > macb_writel(bp, USRIO, 0);
> > > #endif
> > > else
> > > #if defined(CONFIG_ARCH_AT91)
> > > macb_writel(bp, USRIO, MACB_BIT(CLKEN));
> > > #else
> > > macb_writel(bp, USRIO, MACB_BIT(MII));
> > > #endif
> >
> > Ok, but what about non-AT91/AVR32 systems? They may not have a
> > mach/cpu.h and won't have cpu_is_foo() for the platforms the driver is
> > interested in.
> >
> > Could we supply these values in the platform data so the driver doesn't
> > need to do any cpu_is_ magic?
>
> for other arch you can but at91 I prefer to avoid this copy and paste in every
> soc
Ok, just so I'm clear, you want to be able to set the USRIO register
based on a cpu_is_foo() test which requires mach/cpu.h to be included.
For other architectures we may not have mach/cpu.h and the cpu_is_foo()
macros, so we'd still need to protect all of that with "#ifdef
CONFIG_ARCH_AT91" tests. Is that okay?
Jamie
^ permalink raw reply
* Re: [PATCH 4/8] macb: initial support for Cadence GEM
From: Jamie Iles @ 2011-03-11 14:08 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Jamie Iles, netdev, linux-arm-kernel, nicolas.ferre
In-Reply-To: <20110311133445.GP9351@game.jcrosoft.org>
On Fri, Mar 11, 2011 at 02:34:45PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 13:30 Fri 11 Mar , Jamie Iles wrote:
> > On Fri, Mar 11, 2011 at 02:14:15PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > On 10:10 Thu 10 Mar , Jamie Iles wrote:
> > > > The Cadence GEM is based on the MACB Ethernet controller but has a few
> > > > small changes with regards to register and bitfield placement. This
> > > > patch adds a new platform driver for gem which sets allows the driver to
> > > > tell at runtime whether it is targetting a GEM device.
> > > >
> > > > Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> > > could we avoid all this if else everywhere?
> >
> > I can't really see any other way to do this, but you're right it isn't
> > particularly nice. Having said that, it is only in the initialization
> > code so there shouldn't be any real performance impact.
> >
> > I'm open to ideas though!
> use macro or inline at least
Ok, so this works:
#define macb_or_gem_writel(__bp, __reg, __value) \
({ \
if ((__bp)->is_gem) \
gem_writel((__bp), __reg, __value); \
else \
macb_writel((__bp), __reg, __value); \
})
#define macb_or_gem_readl(__bp, __reg) \
({ \
u32 __v; \
if ((__bp)->is_gem) \
__v = gem_readl((__bp), __reg); \
else \
__v = macb_readl((__bp), __reg); \
__v; \
})
and then we can use these for things like the hardware addresses where
the registers are different but I wanted to avoid the conditional in
every register access if possible.
How is this for you? We then only have visible conditionals for the
data bus width (as I don't know if that is something that MACB can do or
what the numbers are) and for the stats collection, but that seems
acceptable to me.
Jamie
^ permalink raw reply
* Re: [Patch V2] bonding: fix netpoll in active-backup mode
From: Andy Gospodarek @ 2011-03-11 14:35 UTC (permalink / raw)
To: Cong Wang
Cc: Andy Gospodarek, linux-kernel, Neil Horman, Jay Vosburgh, netdev
In-Reply-To: <4D7773E3.5050708@redhat.com>
On Wed, Mar 09, 2011 at 08:34:43PM +0800, Cong Wang wrote:
> 于 2011年03月09日 05:24, Andy Gospodarek 写道:
>> On Tue, Mar 08, 2011 at 05:58:56PM +0800, Amerigo Wang wrote:
>>> V2: avoid calling slave_diable_netpoll() with write_lock_bh() held.
>>>
>>> netconsole doesn't work in active-backup mode, because we don't do anything
>>> for nic failover in active-backup mode. We should disable netpoll on the
>>> failing slave when it is detected down and enable netpoll when it becomes
>>> the active slave.
>>>
>>> Tested by ifdown the current active slave and ifup it again for several times,
>>> netconsole works well.
>>>
>>> Signed-off-by: WANG Cong<amwang@redhat.com>
>>> Cc: Neil Horman<nhorman@tuxdriver.com>
>>>
>>
>> It seems like you are going to a lot of trouble to fix a bug where
>> netpoll will not be setup on any interface that is down when enslaved.
>> That seems to be the only path that would not have slave->np setup
>> properly at enslavement.
>>
>> Did you ever try just this?
>
> That was my first thought, but I was over-worried about the failing slave.
> This way should work too. Mind to send it as a normal patch? :)
>
I'm happy to submit the patch if it works in your environment.
I do not think anyone likes un-tested patches.
^ permalink raw reply
* Re: [PATCH 0/6] TCP CUBIC and Hystart
From: Sangtae Ha @ 2011-03-11 15:58 UTC (permalink / raw)
To: Lucas Nussbaum; +Cc: Stephen Hemminger, davem, rhee, netdev
In-Reply-To: <20110311102809.GB15941@xanadu.blop.info>
Hi Lucas,
From your setup, ca->delay_min is 90 and this means the one-way delay
is 90 >> 4 (5ms).
And our gap detection threshold is 2ms, which means that if the gap is
loosely spread over 5ms with delayed ACKs, it can early terminate the
slow start. But, given the optimal cwnd is 941 in your setup, exiting
slow start one RTT before the loss (half of the optimal cwnd) is what
hystart does.
Since the resolution is now ms, can you change the gap detection to
1ms and run it again?
Also, the following change you did doesn't hurt (1ms more train to
detect the ACK train).
if ((s32)(now - ca->round_start) > ca->delay_min >> 4)
I am also testing the algorithm with HZ=100ms and 1000ms in my network
and will share the results soon.
Sangtae
On Fri, Mar 11, 2011 at 5:28 AM, Lucas Nussbaum <lucas.nussbaum@loria.fr> wrote:
> On 10/03/11 at 08:51 -0800, Stephen Hemminger wrote:
>> This patch set is my attempt at addressing the problems discovered
>> by Lucas Nussbaum.
>
> With those patches applied (and the fix I mentioned separately), it
> works much better (still with HZ=250).
>
> When a delayed ack train is detected, slow start ends with cwnd ~= 580
> (sometimes a bit lower).
> When no delayed ack train is detected, slow start ends with the detection of the
> delay increase at cwnd in the [700:1100] range.
>
> performance is still not as good as without hystart, but it is more
> acceptable:
>
> nuttcp -i1 -n1g graphene-34.nancy.grid5000.fr
> 94.8125 MB / 1.00 sec = 795.3059 Mbps 0 retrans
> 112.2500 MB / 1.00 sec = 941.6325 Mbps 0 retrans
> 112.2500 MB / 1.00 sec = 941.6222 Mbps 0 retrans
> 112.2500 MB / 1.00 sec = 941.6335 Mbps 0 retrans
> 112.2500 MB / 1.00 sec = 941.6354 Mbps 0 retrans
> 112.2500 MB / 1.00 sec = 941.6231 Mbps 0 retrans
> 112.2500 MB / 1.00 sec = 941.5883 Mbps 0 retrans
> 112.2500 MB / 1.00 sec = 941.6297 Mbps 0 retrans
> 112.2500 MB / 1.00 sec = 941.6391 Mbps 0 retrans
>
> 1024.0000 MB / 9.29 sec = 924.7155 Mbps 14 %TX 28 %RX 0 retrans 11.39 msRTT
> During that run, no ack train was detected, but delay increase was detected when cwnd=1105:
> hystart_update: cwnd=1105 ssthresh=1105 fnd=2 hs_det=3 cur_rtt=122 delay_min=90 DELTRE=16
>
> However:
> echo 1 > /proc/sys/net/ipv4/route/flush; nuttcp -i1 -n1g graphene-34.nancy.grid5000.fr
> 49.5000 MB / 1.00 sec = 415.2278 Mbps 0 retrans
> 59.0000 MB / 1.00 sec = 494.9318 Mbps 0 retrans
> 62.1875 MB / 1.00 sec = 521.6535 Mbps 0 retrans
> 64.1250 MB / 1.00 sec = 537.9329 Mbps 0 retrans
> 67.0625 MB / 1.00 sec = 562.5486 Mbps 0 retrans
> 69.4375 MB / 1.00 sec = 582.4840 Mbps 0 retrans
> 72.3750 MB / 1.00 sec = 607.1395 Mbps 0 retrans
> 75.3125 MB / 1.00 sec = 631.7557 Mbps 0 retrans
> 83.1250 MB / 1.00 sec = 697.2975 Mbps 0 retrans
> 94.3125 MB / 1.00 sec = 791.1569 Mbps 0 retrans
> 107.6250 MB / 1.00 sec = 902.8194 Mbps 0 retrans
> 112.2500 MB / 1.00 sec = 941.6231 Mbps 0 retrans
>
> 1024.0000 MB / 12.97 sec = 662.2669 Mbps 10 %TX 20 %RX 0 retrans 11.39 msRTT
> [ 3050.712333] found ACK TRAIN: cwnd=493 now=2757023598 ca->last_ack=2757023598 ca->round_start=2757023593 ca->delay_min=90 delay_min>>4=5
> [ 3050.726045] hystart_update: cwnd=493 ssthresh=493 fnd=1 hs_det=3 cur_rtt=91 delay_min=90 DELTRE=16
> (delayed ack train detected when cwnd=493 => slower convergence)
>
> It seems that the ack train length detection is still a bit too sensitive.
> Changing:
> if ((s32)(now - ca->round_start) >= ca->delay_min >> 4)
> To:
> if ((s32)(now - ca->round_start) > ca->delay_min >> 4)
> makes things slightly better, but slow start still exits too early. (optimal cwnd=941).
>
> I'm not sure if we can really do something more about that. The detection by
> ack train length is inherently more likely to trigger false positives since all
> acks are considered, not just a few acks at the beginning of the train. I'm
> tempted to suggest to disable the ack train length detection by default, but
> then it probably solves problems for other people, and the decrease in
> performance is more acceptable now.
> --
> | Lucas Nussbaum MCF Université Nancy 2 |
> | lucas.nussbaum@loria.fr LORIA / AlGorille |
> | http://www.loria.fr/~lnussbau/ +33 3 54 95 86 19 |
>
^ permalink raw reply
* Re: [PATCH 5/6] tcp_cubic: fix clock dependency
From: Sangtae Ha @ 2011-03-11 16:26 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, rhee, netdev
In-Reply-To: <20110310165329.187344604@vyatta.com>
Thanks Stephen.
The patch is useful since I had to increase CA_PRIV_SIZE to use
ktime_t for the testing.
Indeed, CUBIC already used up the limit CA_PRIV_SIZE for its variables.
I've got compilation errors because of "jiffies_to_ms" and I corrected
it to "jiffies_to_msecs"
- return jiffies_to_ms(jiffies);
+ return jiffies_to_msecs(jiffies);
Also, >= instead of <=, which Lucas already found and reported.
- if ((s32)(now - ca->round_start) <= ca->delay_min >> 4)
+ if ((s32)(now - ca->round_start) >= ca->delay_min >> 4)
Sangtae
On Thu, Mar 10, 2011 at 11:51 AM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> The hystart code was written with assumption that HZ=1000.
> Replace the use of jiffies with bictcp_clock as a millisecond
> real time clock.
>
> Warning: this is still experimental, there may still be mistakes
> in units (ms vs. jiffies).
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> P.s: tried using ktime_t but 'struct bictcp' is bumping against limit
> of CA_PRIV_SIZE.
>
> --- a/net/ipv4/tcp_cubic.c 2011-03-10 08:35:45.532695373 -0800
> +++ b/net/ipv4/tcp_cubic.c 2011-03-10 08:35:59.968882888 -0800
> @@ -88,7 +88,7 @@ struct bictcp {
> u32 last_time; /* time when updated last_cwnd */
> u32 bic_origin_point;/* origin point of bic function */
> u32 bic_K; /* time to origin point from the beginning of the current epoch */
> - u32 delay_min; /* min delay */
> + u32 delay_min; /* min delay (msec << 3) */
> u32 epoch_start; /* beginning of an epoch */
> u32 ack_cnt; /* number of acks */
> u32 tcp_cwnd; /* estimated tcp cwnd */
> @@ -98,7 +98,7 @@ struct bictcp {
> u8 found; /* the exit point is found? */
> u32 round_start; /* beginning of each round */
> u32 end_seq; /* end_seq of the round */
> - u32 last_jiffies; /* last time when the ACK spacing is close */
> + u32 last_ack; /* last time when the ACK spacing is close */
> u32 curr_rtt; /* the minimum rtt of current round */
> };
>
> @@ -119,12 +119,21 @@ static inline void bictcp_reset(struct b
> ca->found = 0;
> }
>
> +static inline u32 bictcp_clock(void)
> +{
> +#if HZ < 1000
> + return ktime_to_ms(ktime_get_real());
> +#else
> + return jiffies_to_ms(jiffies);
> +#endif
> +}
> +
> static inline void bictcp_hystart_reset(struct sock *sk)
> {
> struct tcp_sock *tp = tcp_sk(sk);
> struct bictcp *ca = inet_csk_ca(sk);
>
> - ca->round_start = ca->last_jiffies = jiffies;
> + ca->round_start = ca->last_ack = bictcp_clock();
> ca->end_seq = tp->snd_nxt;
> ca->curr_rtt = 0;
> ca->sample_cnt = 0;
> @@ -239,7 +248,7 @@ static inline void bictcp_update(struct
> */
>
> /* change the unit from HZ to bictcp_HZ */
> - t = ((tcp_time_stamp + (ca->delay_min>>3) - ca->epoch_start)
> + t = ((tcp_time_stamp + msecs_to_jiffies(ca->delay_min>>3) - ca->epoch_start)
> << BICTCP_HZ) / HZ;
>
> if (t < ca->bic_K) /* t - K */
> @@ -342,14 +351,12 @@ static void hystart_update(struct sock *
> struct bictcp *ca = inet_csk_ca(sk);
>
> if (!(ca->found & hystart_detect)) {
> - u32 curr_jiffies = jiffies;
> + u32 now = bictcp_clock();
>
> /* first detection parameter - ack-train detection */
> - if ((s32)(curr_jiffies - ca->last_jiffies) <=
> - msecs_to_jiffies(hystart_ack_delta)) {
> - ca->last_jiffies = curr_jiffies;
> - if ((s32) (curr_jiffies - ca->round_start) <=
> - ca->delay_min >> 4)
> + if ((s32)(now - ca->last_ack) <= hystart_ack_delta) {
> + ca->last_ack = now;
> + if ((s32)(now - ca->round_start) <= ca->delay_min >> 4)
> ca->found |= HYSTART_ACK_TRAIN;
> }
>
> @@ -396,7 +403,7 @@ static void bictcp_acked(struct sock *sk
> if ((s32)(tcp_time_stamp - ca->epoch_start) < HZ)
> return;
>
> - delay = usecs_to_jiffies(rtt_us) << 3;
> + delay = (rtt_us << 3) / USEC_PER_MSEC;
> if (delay == 0)
> delay = 1;
>
>
>
>
^ permalink raw reply
* Re: [PATCH 0/6] TCP CUBIC and Hystart
From: Lucas Nussbaum @ 2011-03-11 16:08 UTC (permalink / raw)
To: Sangtae Ha; +Cc: Stephen Hemminger, davem, rhee, netdev
In-Reply-To: <AANLkTimi+nJ1-PO+JYjckg-Pw3+6-zJvqPvhMjf+1Lua@mail.gmail.com>
On 11/03/11 at 10:58 -0500, Sangtae Ha wrote:
> Hi Lucas,
>
> From your setup, ca->delay_min is 90 and this means the one-way delay
> is 90 >> 4 (5ms).
> And our gap detection threshold is 2ms, which means that if the gap is
> loosely spread over 5ms with delayed ACKs, it can early terminate the
> slow start. But, given the optimal cwnd is 941 in your setup, exiting
> slow start one RTT before the loss (half of the optimal cwnd) is what
> hystart does.
>
> Since the resolution is now ms, can you change the gap detection to
> 1ms and run it again?
> Also, the following change you did doesn't hurt (1ms more train to
> detect the ACK train).
Hi,
Changing it to 1ms only improves the situation marginally.
[25271.861481] found ACK TRAIN: cwnd=835 now=2779244747 ca->last_ack=2779244747 ca->round_start=2779244741 ca->delay_min=90 delay_min>>4=5 nbacks=261
[25291.507340] found ACK TRAIN: cwnd=585 now=2779264393 ca->last_ack=2779264393 ca->round_start=2779264387 ca->delay_min=90 delay_min>>4=5 nbacks=221
[25327.585396] found ACK TRAIN: cwnd=1034 now=2779300471 ca->last_ack=2779300471 ca->round_start=2779300465 ca->delay_min=90 delay_min>>4=5 nbacks=245
[25347.300351] found ACK TRAIN: cwnd=1463 now=2779320186 ca->last_ack=2779320186 ca->round_start=2779320180 ca->delay_min=90 delay_min>>4=5 nbacks=427
[25390.702328] found ACK TRAIN: cwnd=587 now=2779363588 ca->last_ack=2779363588 ca->round_start=2779363582 ca->delay_min=90 delay_min>>4=5 nbacks=211
[25394.775396] found ACK TRAIN: cwnd=588 now=2779367661 ca->last_ack=2779367661 ca->round_start=2779367655 ca->delay_min=90 delay_min>>4=5 nbacks=242
[25402.061328] found ACK TRAIN: cwnd=1282 now=2779374947 ca->last_ack=2779374947 ca->round_start=2779374941 ca->delay_min=90 delay_min>>4=5 nbacks=335
[25404.894336] found ACK TRAIN: cwnd=585 now=2779377780 ca->last_ack=2779377780 ca->round_start=2779377774 ca->delay_min=90 delay_min>>4=5 nbacks=205
[25408.584337] found ACK TRAIN: cwnd=587 now=2779381470 ca->last_ack=2779381470 ca->round_start=2779381464 ca->delay_min=90 delay_min>>4=5 nbacks=209
[25421.699331] found ACK TRAIN: cwnd=856 now=2779394585 ca->last_ack=2779394585 ca->round_start=2779394579 ca->delay_min=90 delay_min>>4=5 nbacks=239
There are still some cases when ack trains are detected too early.
--
| Lucas Nussbaum MCF Université Nancy 2 |
| lucas.nussbaum@loria.fr LORIA / AlGorille |
| http://www.loria.fr/~lnussbau/ +33 3 54 95 86 19 |
^ permalink raw reply
* Re: how to utilize multi tx queue to sent packets
From: Stephen Hemminger @ 2011-03-11 17:06 UTC (permalink / raw)
To: Jon Zhou; +Cc: netdev@vger.kernel.org
In-Reply-To: <4A6A2125329CFD4D8CC40C9E8ABCAB9F24FB3D3D62@MILEXCH2.ds.jdsu.net>
On Thu, 10 Mar 2011 22:52:30 -0800
Jon Zhou <Jon.Zhou@jdsu.com> wrote:
> hi
>
> I am doing some test according to the
> website:http://wiki.ipxwarzone.com/index.php5?title=Linux_packet_mmap
>
> use packet_mmap tx_ring to send packet.
>
> I modified the sample code "packetmmap.c" to make it send packets have different outer ip.
> so that with the help of RSS, I can achieve higher throughput.
>
> but one thing I saw at the tx side, is that all the packets are sent via the same tx_queue,
> which is conflict with what I saw at the rx side.
> any idea to make it sent packets via different tx_queues? (spread across the tx_queues)
You need to have multiple threads to get Tx scaling.
In you case that also means multiple AF_PACKET sockets and separate rings.
Or just run multiple copies of the same test each with a different IP
^ permalink raw reply
* [PATCH] macb: detect IP version to determin if we are on at91 or avr32
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-03-11 17:13 UTC (permalink / raw)
To: linux-arm-kernel
Cc: netdev, linux-kernel, Jean-Christophe PLAGNIOL-VILLARD,
Hans-Christian Egtvedt, Nicolas Ferre, Jamie Iles
this will make macb soc generic and will allow to use it on other arch
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jamie Iles <jamie@jamieiles.com>
---
drivers/net/macb.c | 96 +++++++++++++++++++++++++---------------------------
drivers/net/macb.h | 9 +++++
2 files changed, 55 insertions(+), 50 deletions(-)
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index f251866..58cebf2 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -22,7 +22,6 @@
#include <linux/phy.h>
#include <mach/board.h>
-#include <mach/cpu.h>
#include "macb.h"
@@ -1140,28 +1139,30 @@ static int __init macb_probe(struct platform_device *pdev)
spin_lock_init(&bp->lock);
-#if defined(CONFIG_ARCH_AT91)
- bp->pclk = clk_get(&pdev->dev, "macb_clk");
- if (IS_ERR(bp->pclk)) {
- dev_err(&pdev->dev, "failed to get macb_clk\n");
- goto err_out_free_dev;
- }
- clk_enable(bp->pclk);
-#else
- bp->pclk = clk_get(&pdev->dev, "pclk");
- if (IS_ERR(bp->pclk)) {
- dev_err(&pdev->dev, "failed to get pclk\n");
- goto err_out_free_dev;
- }
- bp->hclk = clk_get(&pdev->dev, "hclk");
- if (IS_ERR(bp->hclk)) {
- dev_err(&pdev->dev, "failed to get hclk\n");
- goto err_out_put_pclk;
- }
+ bp->version = macb_readl(bp, VERSION);
- clk_enable(bp->pclk);
- clk_enable(bp->hclk);
-#endif
+ if (macb_is_at91(bp)) {
+ bp->pclk = clk_get(&pdev->dev, "macb_clk");
+ if (IS_ERR(bp->pclk)) {
+ dev_err(&pdev->dev, "failed to get macb_clk\n");
+ goto err_out_free_dev;
+ }
+ clk_enable(bp->pclk);
+ } else {
+ bp->pclk = clk_get(&pdev->dev, "pclk");
+ if (IS_ERR(bp->pclk)) {
+ dev_err(&pdev->dev, "failed to get pclk\n");
+ goto err_out_free_dev;
+ }
+ bp->hclk = clk_get(&pdev->dev, "hclk");
+ if (IS_ERR(bp->hclk)) {
+ dev_err(&pdev->dev, "failed to get hclk\n");
+ goto err_out_put_pclk;
+ }
+
+ clk_enable(bp->pclk);
+ clk_enable(bp->hclk);
+ }
bp->regs = ioremap(regs->start, regs->end - regs->start + 1);
if (!bp->regs) {
@@ -1191,18 +1192,17 @@ static int __init macb_probe(struct platform_device *pdev)
macb_get_hwaddr(bp);
pdata = pdev->dev.platform_data;
- if (pdata && pdata->is_rmii)
-#if defined(CONFIG_ARCH_AT91)
- macb_writel(bp, USRIO, (MACB_BIT(RMII) | MACB_BIT(CLKEN)) );
-#else
- macb_writel(bp, USRIO, 0);
-#endif
- else
-#if defined(CONFIG_ARCH_AT91)
- macb_writel(bp, USRIO, MACB_BIT(CLKEN));
-#else
- macb_writel(bp, USRIO, MACB_BIT(MII));
-#endif
+ if (pdata && pdata->is_rmii) {
+ if (macb_is_at91(bp))
+ macb_writel(bp, USRIO, (MACB_BIT(RMII) | MACB_BIT(CLKEN)));
+ else
+ macb_writel(bp, USRIO, 0);
+ } else {
+ if (macb_is_at91(bp))
+ macb_writel(bp, USRIO, MACB_BIT(CLKEN));
+ else
+ macb_writel(bp, USRIO, MACB_BIT(MII));
+ }
bp->tx_pending = DEF_TX_RING_PENDING;
@@ -1245,14 +1245,12 @@ err_out_unregister_netdev:
err_out_iounmap:
iounmap(bp->regs);
err_out_disable_clocks:
-#ifndef CONFIG_ARCH_AT91
- clk_disable(bp->hclk);
- clk_put(bp->hclk);
-#endif
+ if (!macb_is_at91(bp)) {
+ clk_disable(bp->hclk);
+ clk_put(bp->hclk);
+ }
clk_disable(bp->pclk);
-#ifndef CONFIG_ARCH_AT91
err_out_put_pclk:
-#endif
clk_put(bp->pclk);
err_out_free_dev:
free_netdev(dev);
@@ -1278,10 +1276,10 @@ static int __exit macb_remove(struct platform_device *pdev)
unregister_netdev(dev);
free_irq(dev->irq, dev);
iounmap(bp->regs);
-#ifndef CONFIG_ARCH_AT91
- clk_disable(bp->hclk);
- clk_put(bp->hclk);
-#endif
+ if (!macb_is_at91(bp)) {
+ clk_disable(bp->hclk);
+ clk_put(bp->hclk);
+ }
clk_disable(bp->pclk);
clk_put(bp->pclk);
free_netdev(dev);
@@ -1299,9 +1297,8 @@ static int macb_suspend(struct platform_device *pdev, pm_message_t state)
netif_device_detach(netdev);
-#ifndef CONFIG_ARCH_AT91
- clk_disable(bp->hclk);
-#endif
+ if (!macb_is_at91(bp))
+ clk_disable(bp->hclk);
clk_disable(bp->pclk);
return 0;
@@ -1313,9 +1310,8 @@ static int macb_resume(struct platform_device *pdev)
struct macb *bp = netdev_priv(netdev);
clk_enable(bp->pclk);
-#ifndef CONFIG_ARCH_AT91
- clk_enable(bp->hclk);
-#endif
+ if (!macb_is_at91(bp))
+ clk_enable(bp->hclk);
netif_device_attach(netdev);
diff --git a/drivers/net/macb.h b/drivers/net/macb.h
index d3212f6..56a4fcb 100644
--- a/drivers/net/macb.h
+++ b/drivers/net/macb.h
@@ -59,6 +59,7 @@
#define MACB_TPQ 0x00bc
#define MACB_USRIO 0x00c0
#define MACB_WOL 0x00c4
+#define MACB_VERSION 0x00fc
/* Bitfields in NCR */
#define MACB_LB_OFFSET 0
@@ -389,6 +390,14 @@ struct macb {
unsigned int link;
unsigned int speed;
unsigned int duplex;
+
+ uint32_t version;
};
+#define MACB_VERSION_MASK 0xffff0000
+#define macb_is_at91(bp) \
+ (((bp)->version & MACB_VERSION_MASK) == 0x06010000)
+#define macb_is_avr32(bp) \
+ (((bp)->version & MACB_VERSION_MASK) == 0x00010000)
+
#endif /* _MACB_H */
--
1.7.4.1
^ permalink raw reply related
* Re: [GIT/PATCH v4] xen network backend driver
From: Stephen Hemminger @ 2011-03-11 17:24 UTC (permalink / raw)
To: Ian Campbell
Cc: Ben Hutchings, netdev@vger.kernel.org, xen-devel,
Jeremy Fitzhardinge, Herbert Xu, Konrad Rzeszutek Wilk,
Francois Romieu
In-Reply-To: <1299838975.17339.1882.camel@zakaz.uk.xensource.com>
On Fri, 11 Mar 2011 10:22:55 +0000
Ian Campbell <Ian.Campbell@eu.citrix.com> wrote:
> On Thu, 2011-03-10 at 17:30 +0000, Ben Hutchings wrote:
> > On Thu, 2011-03-10 at 09:15 -0800, Stephen Hemminger wrote:
> > > On Thu, 10 Mar 2011 17:02:33 +0000
> > > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > > +struct xenvif {
> > > > + /* Unique identifier for this interface. */
> > > ...
> > > > + struct net_device_stats stats;
> > > > +
> > >
> > > There is already a stats struct in net_device in current kernel
> > > versions, unless there is a compelling reason otherwise
> > > please use that.
>
> Will do.
>
> > > Also, you probably want to implement per-cpu and 64 bit
> > > stats.
> >
> > The driver is using a single queue, so I don't see what benefit it would
> > get from per-cpu stats. At some point it should become multiqueue and
> > then it should store per-queue stats.
>
> Agreed.
>
> > 64-bit stats are definitely preferable, but since they're being
> > maintained on the data path this may require some significant work.
> > (Ian: see <linux/u64_stats_sync.h> for the canonical way to do this.)
> > Given that only a relatively few existing drivers do this (I count 13),
> > I'm not sure we can reasonably demand that a new driver does - yet.
>
> Is there an example of a driver which also updates the stats on the
> datapath?
>
> If it's ok I'd prefer to defer this change for now though.
Sure, my original comment was just a hint for future.
--
^ permalink raw reply
* Re: [net-next-2.6 00/11][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2011-03-11 19:06 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips
In-Reply-To: <1299841590-30676-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 11 Mar 2011 03:06:19 -0800
> The following series contains FCoE documentation update, ixgb conversion
> to the new VLAN model, several fixes and cleanups for e1000e and
> the removal of Tx hang detection in ixgbevf (like recent igbvf patch).
>
> The following are changes since commit 1b7fe59322bef9e7a2c05b64a07a66b875299736:
> ipv4: Kill flowi arg to fib_select_multipath()
>
> and are available in the git repository at:
> master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next-2.6 master
Does this one actually compile? :-)
^ permalink raw reply
* Re: [Bugme-new] [Bug 29252] New: IPv6 doesn't work in a kvm guest.
From: Ernst Sjöstrand @ 2011-03-11 19:44 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, bugzilla-daemon, bugme-daemon, slash
In-Reply-To: <20110309.200437.226773227.davem@davemloft.net>
Hi,
this patch solved the issue I reported. Applied the patch on -rc8.
Regards
//Ernst
On Thu, Mar 10, 2011 at 05:04, David Miller <davem@davemloft.net> wrote:
> From: David Miller <davem@davemloft.net>
> Date: Wed, 09 Mar 2011 19:20:12 -0800 (PST)
>
>> From: David Miller <davem@davemloft.net>
>> Date: Wed, 09 Mar 2011 15:58:18 -0800 (PST)
>>
>>> Ok, the following should address both bugs, #29252 and #30462, please
>>> give it some testing.
>>>
>>> --------------------
>>> ipv6: Don't create clones of nonexthop routes forever.
>>
>> Nevermind, this patch has problems, I'm still debugging and trying to
>> come up with a proper fix.
>>
>> Thanks in advance for your patience.
>
> Ok, I'm more confident in this version of the fix. It passes all of
> my tests, and I've added instrumentation to make sure various cases
> are performing the operations the way I expect them to.
>
> --------------------
> ipv6: Don't create clones of host routes.
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Addresses https://bugzilla.kernel.org/show_bug.cgi?id=29252
> Addresses https://bugzilla.kernel.org/show_bug.cgi?id=30462
>
> In commit d80bc0fd262ef840ed4e82593ad6416fa1ba3fc4 ("ipv6: Always
> clone offlink routes.") we forced the kernel to always clone offlink
> routes.
>
> The reason we do that is to make sure we never bind an inetpeer to a
> prefixed route.
>
> The logic turned on here has existed in the tree for many years,
> but was always off due to a protecting CPP define. So perhaps
> it's no surprise that there is a logic bug here.
>
> The problem is that we canot clone a route that is already a
> host route (ie. has DST_HOST set). Because if we do, an identical
> entry already exists in the routing tree and therefore the
> ip6_rt_ins() call is going to fail.
>
> This sets off a series of failures and high cpu usage, because when
> ip6_rt_ins() fails we loop retrying this operation a few times in
> order to handle a race between two threads trying to clone and insert
> the same host route at the same time.
>
> Fix this by simply using the route as-is when DST_HOST is set.
>
> Reported-by: slash@ac.auone-net.jp
> Reported-by: Ernst Sjöstrand <ernstp@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> net/ipv6/route.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 904312e..e7db701 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -739,8 +739,10 @@ restart:
>
> if (!rt->rt6i_nexthop && !(rt->rt6i_flags & RTF_NONEXTHOP))
> nrt = rt6_alloc_cow(rt, &fl->fl6_dst, &fl->fl6_src);
> - else
> + else if (!(rt->dst.flags & DST_HOST))
> nrt = rt6_alloc_clone(rt, &fl->fl6_dst);
> + else
> + goto out2;
>
> dst_release(&rt->dst);
> rt = nrt ? : net->ipv6.ip6_null_entry;
> --
> 1.7.4.1
>
>
^ permalink raw reply
* Re: [GIT] Networking
From: Greg KH @ 2011-03-11 19:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dave Airlie, David Miller, akpm, netdev, linux-kernel
In-Reply-To: <AANLkTi=F=za4OaNbiT71oTj+HKZG1sJE=YrrjpUb4AS7@mail.gmail.com>
On Thu, Mar 10, 2011 at 04:57:04PM -0800, Linus Torvalds wrote:
> But now that I've done it once, maybe I'm hooked. It's like coke to
> Charlie Sheen.
Did you ever push this networking pull out? I don't seem to be seeing
it in your tree, but the --no-ff might have caused me to miss it.
thanks,
greg k-h
^ permalink raw reply
* Re: [Bugme-new] [Bug 29252] New: IPv6 doesn't work in a kvm guest.
From: David Miller @ 2011-03-11 20:15 UTC (permalink / raw)
To: ernstp; +Cc: akpm, netdev, bugzilla-daemon, bugme-daemon, slash
In-Reply-To: <AANLkTi=T35ghBWJKu+fimXnJczRjy9GzY+H_6GiNbgHE@mail.gmail.com>
From: Ernst Sjöstrand <ernstp@gmail.com>
Date: Fri, 11 Mar 2011 20:44:39 +0100
> this patch solved the issue I reported. Applied the patch on -rc8.
Thank you for testing.
^ permalink raw reply
* Re: [GIT] Networking
From: J. Bruce Fields @ 2011-03-11 20:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Miller, akpm, netdev, linux-kernel
In-Reply-To: <AANLkTik3AyFTNoytebmOOZ=JSFMkt0bw7au-CSncUHJu@mail.gmail.com>
On Thu, Mar 10, 2011 at 04:29:30PM -0800, Linus Torvalds wrote:
> On Thu, Mar 10, 2011 at 3:55 PM, David Miller <davem@davemloft.net> wrote:
> > I should have put:
> >
> > Merge to get commit 8909c9ad8ff03611c9c96c9a92656213e4bb495b
> > ("net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules")
> > so that we can add Stephen Hemminger's fix to handle ip6 tunnels
> > as well, which uses the MODULE_ALIAS_NETDEV() macro created by
> > that change.
>
> Yeah, that would have explained it. That said, if you are merging for
> something like that, may I suggest actually starting off with
>
> git merge 8909c9ad8ff03611c9c96c9a92656213e4bb495b
>
> that then actually makes the history itself also show the relationship
> (you'd still have to write the commit message explaining why,
By the way, I occasionally wonder whether it would make sense to make a
habit of committing bugfixes on top of the commit that introduced the
bug (at least in cases where there *is* a single commit that introduced
the bug).
As with the above, it'd make the history a little more self-documenting.
It might simplify life for backporters. (In theory, they could do
merges instead of a cherry-picks if they wanted to.) The set of "bad"
commits would be described by "fix^...fix".
But then I had some mental image if your saying "WTF?" the first time I
send you a post-rc1 pull request that looks like an octopus merge of a
dozen little 1- or 2- commit branches based all over the place.
I dunno, would it be annoying?
--b.
^ permalink raw reply
* Re: [GIT] Networking
From: David Miller @ 2011-03-11 21:01 UTC (permalink / raw)
To: bfields; +Cc: torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20110311204823.GB7906@fieldses.org>
From: "J. Bruce Fields" <bfields@fieldses.org>
Date: Fri, 11 Mar 2011 15:48:23 -0500
> As with the above, it'd make the history a little more self-documenting.
Once there is even one single commit after the buggy one, this is
simply impossible since the hashes of subsequent commits depend upon
the precise contents of the original one.
^ permalink raw reply
* pull request: wireless-next-2.6 2011-03-11
From: John W. Linville @ 2011-03-11 21:06 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Dave,
Welcome to this week's installment of updates from the wireless world
intended for 2.6.39... :-) The biggest notables here are a bluetooth
pull from Gustavo, a wl12xx pull from Luca, and a number of rt2x00
updates, along with the usual smattering of various driver updates
and small enhancements and fixes here and there.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 1b7fe59322bef9e7a2c05b64a07a66b875299736:
ipv4: Kill flowi arg to fib_select_multipath() (2011-03-10 17:03:45 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git for-davem
Anand Gadiyar (2):
Bluetooth: fix build break on hci_sock.c
Bluetooth: remove unnecessary call to hci_sock_cleanup
Anderson Briglia (1):
Bluetooth: Fix LE conn creation
Arik Nemtsov (1):
wl12xx: wakeup chip from ELP during scan
Ben Greear (2):
ath9k: Fix txq memory address printing in debugfs.
ath5k: Put hardware in PROMISC mode if there is more than 1 stations.
Bing Zhao (1):
ieee80211: add IEEE80211_COUNTRY_STRING_LEN definition
Daniel Halperin (1):
mac80211: update minstrel_ht sample rate when probe is set
Fry, Donald H (1):
iwlagn: report correct temperature for WiFi/BT devices.
Gabor Juhos (1):
rt2x00: fix whitespace damage in the rt2800 specific code
Gertjan van Wingerde (4):
rt2x00: Don't treat ATIM queue as second beacon queue.
rt2x00: Include ATIM queue support in rt2x00queue_get_tx_queue.
rt2x00: Optimize getting the beacon queue structure.
rt2x00: Remove unused rt2x00queue_get_queue function.
Gustavo F. Padovan (1):
Bluetooth: Remove duplicated BT_INFO() from L2CAP
Helmut Schaa (16):
wl12xx: Correctly set up protection if non-GF STAs are present
rt2x00: Optimize calls to rt2x00queue_get_queue
rt2x00: Make use of unlikely during tx status processing
rt2x00: Remove useless NULL check
rt2x00: Add unlikely macro to special case tx status handling
rt2x00: Use unlikely for unexpected error condition in rt2x00_mac_tx
rt2x00: Generate sw sequence numbers only for devices that need it
rt2x00: Optimize TX descriptor handling
rt2x00: Move TX descriptor field "ifs" into plcp substruct
rt2x00: Don't call ieee80211_get_tx_rate for MCS rates
rt2x00: Use an enum instead of u16 for the rate_mode TX descriptor field
rt2x00: Fix rt2800 key assignment in multi bssid setups
rt2x00: Remove now unused crypto.aid field
rt2x00: Revise irqmask locking for PCI devices
rt2x00: Fix comment in rt2800pci
mac80211: Remove redundant preamble and RTS flag setup in minstrel_ht
Ido Yariv (9):
wl12xx: Don't rely on runtime PM for toggling power
wl12xx: Remove private headers in wl1271_tx_reset
wl12xx: Reorder data handling in irq_work
wl12xx: Do end-of-transactions transfers only if needed
wl12xx: Change claiming of the SDIO bus
wl12xx: Switch to a threaded interrupt handler
wl12xx: Switch to level trigger interrupts
wl12xx: Avoid redundant TX work
wl12xx: Modify requested number of memory blocks
Ivo van Doorn (1):
rt2x00: Optimize TX descriptor memory layout
Johan Hedberg (8):
Bluetooth: Make pending_add return a pointer to the added entry
Bluetooth: Add mgmt_pair_device command
Bluetooth: Add management support for user confirmation request
Bluetooth: Fix mgmt_pin_code_reply command status opcode
Bluetooth: Fix mgmt_pin_code_reply return parameters
Bluetooth: Add mgmt_auth_failed event
Bluetooth: Fix inititial value for remote authentication requirements
Bluetooth: Fix unnecessary list traversal in mgmt_pending_remove
Johannes Berg (1):
mac80211: fix scan race, simplify code
John W. Linville (6):
Merge branch 'master' of git://git.kernel.org/.../padovan/bluetooth-next-2.6
Merge branch 'for-linville' of git://git.kernel.org/.../luca/wl12xx
Merge branch 'wireless-next-2.6' of git://git.kernel.org/.../iwlwifi/iwlwifi-2.6
rtlwifi: usb parts should depend on CONFIG_USB
ath5k: restrict AR5K_TX_QUEUE_ID_DATA_MAX to reflect the [0,3] range
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next-2.6 into for-davem
Larry Finger (1):
rtl8187: Change rate-control feedback
Michael Buesch (3):
lib-average: Make config option selectable
mac80211: Add log message to ieee80211_restart_hw()
p54spi: Update kconfig help text
Rafał Miłecki (4):
b43: N-PHY: rev3+: correct switching analog core
b43: N-PHY: rev3+: add tables with gain ctl workarounds
b43: N-PHY: rev3+: implement gain ctl workarounds
b43: trivial: update B43_PHY_N description (PHY support)
Scott James Remnant (1):
net/wireless: add COUNTRY to to regulatory device uevent
Sebastien Jan (1):
wl12xx: fix the path to the wl12xx firmwares
Shan Wei (3):
mac80211: remove unused macros
wireless:ath: use resource_size() help function
mwl8k: use kcalloc instead of kmalloc & memset
Stanislaw Gruszka (4):
iwlwifi: move rx handlers code to iwl-rx.c
iwlwifi: cleanup iwl_good_plcp_health
iwlwifi: avoid too frequent recover from statistics
iwlwifi: fix iwl-rx.c compilation
Szymon Janc (8):
Bluetooth: Use proper command structure in remove_uuid
Bluetooth: Move index to common header in management interface
Bluetooth: Validate data size before accessing mgmt commands
Bluetooth: Fix possible NULL pointer dereference in cmd_complete
Bluetooth: Log all parameters in cmd_status for easier debugging
Bluetooth: Remove unused code from get_connections
Bluetooth: Use variable name instead of type in sizeof()
Bluetooth: Fix some small code style issues in mgmt.c
Vasanthakumar Thiagarajan (2):
ath9k: Add a debugfs interface to dump chip registers
ath9k_hw: Read noise floor only for available chains for AR9003
Ville Tervo (1):
Bluetooth: Use ERR_PTR as return error from hci_connect
drivers/net/wireless/at76c50x-usb.h | 2 +-
drivers/net/wireless/ath/ath5k/ahb.c | 2 +-
drivers/net/wireless/ath/ath5k/ath5k.h | 2 +-
drivers/net/wireless/ath/ath5k/base.c | 52 +-
drivers/net/wireless/ath/ath5k/base.h | 13 +
drivers/net/wireless/ath/ath5k/mac80211-ops.c | 19 +-
drivers/net/wireless/ath/ath9k/ahb.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 37 +-
drivers/net/wireless/ath/ath9k/debug.c | 62 ++-
drivers/net/wireless/b43/Kconfig | 2 +-
drivers/net/wireless/b43/phy_n.c | 179 ++++++-
drivers/net/wireless/b43/tables_nphy.c | 103 ++++
drivers/net/wireless/b43/tables_nphy.h | 25 +
drivers/net/wireless/ipw2x00/ipw2200.h | 2 +-
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 242 +--------
drivers/net/wireless/iwlwifi/iwl-agn.c | 178 +------
drivers/net/wireless/iwlwifi/iwl-agn.h | 13 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 63 --
drivers/net/wireless/iwlwifi/iwl-core.h | 18 +-
drivers/net/wireless/iwlwifi/iwl-dev.h | 4 +-
drivers/net/wireless/iwlwifi/iwl-rx.c | 665 ++++++++++++++++++----
drivers/net/wireless/libertas/host.h | 2 +-
drivers/net/wireless/mwl8k.c | 6 +-
drivers/net/wireless/p54/Kconfig | 5 +-
drivers/net/wireless/rt2x00/rt2400pci.c | 36 +-
drivers/net/wireless/rt2x00/rt2500pci.c | 38 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 13 +-
drivers/net/wireless/rt2x00/rt2800.h | 40 +-
drivers/net/wireless/rt2x00/rt2800lib.c | 753 ++++++++++++------------
drivers/net/wireless/rt2x00/rt2800pci.c | 33 +-
drivers/net/wireless/rt2x00/rt2800usb.c | 1 +
drivers/net/wireless/rt2x00/rt2x00.h | 26 +-
drivers/net/wireless/rt2x00/rt2x00ht.c | 28 +-
drivers/net/wireless/rt2x00/rt2x00mac.c | 20 +-
drivers/net/wireless/rt2x00/rt2x00queue.c | 109 ++--
drivers/net/wireless/rt2x00/rt2x00queue.h | 29 +-
drivers/net/wireless/rt2x00/rt61pci.c | 31 +-
drivers/net/wireless/rt2x00/rt73usb.c | 14 +-
drivers/net/wireless/rtl818x/rtl8187/dev.c | 25 +-
drivers/net/wireless/rtl818x/rtl8187/rtl8187.h | 2 +
drivers/net/wireless/rtlwifi/Makefile | 9 +-
drivers/net/wireless/wl1251/wl12xx_80211.h | 3 +-
drivers/net/wireless/wl12xx/acx.c | 3 +-
drivers/net/wireless/wl12xx/boot.c | 3 +
drivers/net/wireless/wl12xx/boot.h | 5 +
drivers/net/wireless/wl12xx/cmd.c | 1 +
drivers/net/wireless/wl12xx/debugfs.c | 2 +-
drivers/net/wireless/wl12xx/io.h | 1 +
drivers/net/wireless/wl12xx/main.c | 170 ++++--
drivers/net/wireless/wl12xx/ps.c | 6 +-
drivers/net/wireless/wl12xx/ps.h | 2 +-
drivers/net/wireless/wl12xx/rx.c | 11 +-
drivers/net/wireless/wl12xx/scan.c | 20 +-
drivers/net/wireless/wl12xx/sdio.c | 42 +-
drivers/net/wireless/wl12xx/spi.c | 19 +-
drivers/net/wireless/wl12xx/tx.c | 47 ++-
drivers/net/wireless/wl12xx/wl12xx.h | 28 +-
drivers/net/wireless/wl12xx/wl12xx_80211.h | 3 +-
include/linux/ieee80211.h | 3 +
include/net/bluetooth/hci.h | 17 +
include/net/bluetooth/hci_core.h | 21 +
include/net/bluetooth/mgmt.h | 73 ++-
lib/Kconfig | 9 +-
net/bluetooth/af_bluetooth.c | 4 +-
net/bluetooth/hci_conn.c | 8 +-
net/bluetooth/hci_event.c | 69 ++-
net/bluetooth/hci_sock.c | 2 +-
net/bluetooth/l2cap_core.c | 13 +-
net/bluetooth/mgmt.c | 751 ++++++++++++++++--------
net/bluetooth/sco.c | 7 +-
net/mac80211/key.h | 1 -
net/mac80211/main.c | 3 +
net/mac80211/rc80211_minstrel_ht.c | 19 +-
net/mac80211/rc80211_pid.h | 3 -
net/mac80211/scan.c | 64 +--
net/mac80211/work.c | 1 -
net/wireless/reg.c | 39 +-
net/wireless/reg.h | 1 +
78 files changed, 2610 insertions(+), 1769 deletions(-)
Omnibus patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2011-03-11.patch.bz2
--
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: [GIT] Networking
From: Ben Hutchings @ 2011-03-11 21:17 UTC (permalink / raw)
To: David Miller; +Cc: bfields, torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20110311.130128.71121155.davem@davemloft.net>
On Fri, 2011-03-11 at 13:01 -0800, David Miller wrote:
> From: "J. Bruce Fields" <bfields@fieldses.org>
> Date: Fri, 11 Mar 2011 15:48:23 -0500
>
> > As with the above, it'd make the history a little more self-documenting.
>
> Once there is even one single commit after the buggy one, this is
> simply impossible since the hashes of subsequent commits depend upon
> the precise contents of the original one.
I think Bruce is suggesting that the fix is committed on a branch from
the broken commit, then merged into whatever branches need it. I'm not
sure how much that helps, though. The merge could then involve forward-
porting (as opposed to the current situation where fixes are cherry-
picked and possibly back-ported).
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ 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