* [PATCH 2.6.24 1/3][BNX2]: Add missing napi_disable() in bnx2_close().
From: Michael Chan @ 2007-10-03 0:23 UTC (permalink / raw)
To: davem; +Cc: netdev
[BNX2]: Add missing napi_disable() in bnx2_close().
bnx2_close() -> bnx2_netif_stop() will not call napi_disable() because
the netif_state is not running in bnx2_close(). To avoid confusion,
we change it to disable interrupt and napi directly in bnx2_close().
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index cd5f1b7..4887c31 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -5212,8 +5212,8 @@ bnx2_close(struct net_device *dev)
while (bp->in_reset_task)
msleep(1);
- /* This does napi_disable() for us. */
- bnx2_netif_stop(bp);
+ bnx2_disable_int_sync(bp);
+ napi_disable(&bp->napi);
del_timer_sync(&bp->timer);
if (bp->flags & NO_WOL_FLAG)
reset_code = BNX2_DRV_MSG_CODE_UNLOAD_LNK_DN;
^ permalink raw reply related
* Re: tcp bw in 2.6
From: Rick Jones @ 2007-10-02 22:59 UTC (permalink / raw)
To: Larry McVoy; +Cc: David Miller, torvalds, herbert, wscott, netdev
In-Reply-To: <20071002223644.GA14331@bitmover.com>
Larry McVoy wrote:
> On Tue, Oct 02, 2007 at 03:32:16PM -0700, David Miller wrote:
>
>>I'm starting to have a theory about what the bad case might
>>be.
>>
>>A strong sender going to an even stronger receiver which can
>>pull out packets into the process as fast as they arrive.
>>This might be part of what keeps the receive window from
>>growing.
>
>
> I can back you up on that. When I straced the receiving side that goes
> slowly, all the reads were short, like 1-2K. The way that works the
> reads were a lot larger as I recall.
Indeed I was getting more like 8K on each recv() call per netperf's -v 2 stats,
but the system was more than fast enough to stay ahead of the traffic. On the
hunch that it was the interrupt throttling which was keeping the recv's large
rather than the speed of the system(s) I nuked the InterruptThrottleRate to 0
and was able to get between 1900 and 2300 byte recvs on the TCP_STREAM and
TCP_MAERTS tests and still had 940 Mbit/s in each direction.
hpcpc106:~# netperf -H 192.168.7.107 -t TCP_STREAM -v 2 -c -C
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.7.107
(192.168.7.107) port 0 AF_INET
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
87380 87380 87380 10.02 940.95 10.75 21.65 3.743 7.540
Alignment Offset Bytes Bytes Sends Bytes Recvs
Local Remote Local Remote Xfered Per Per
Send Recv Send Recv Send (avg) Recv (avg)
8 8 0 0 1.179e+09 87386.29 13491 1965.77 599729
Maximum
Segment
Size (bytes)
1448
hpcpc106:~# netperf -H 192.168.7.107 -t TCP_MAERTS -v 2 -c -C
TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.7.107
(192.168.7.107) port 0 AF_INET
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
87380 87380 87380 10.02 940.82 20.44 10.61 7.117 3.696
Alignment Offset Bytes Bytes Recvs Bytes Sends
Local Remote Local Remote Xfered Per Per
Recv Send Recv Send Recv (avg) Send (avg)
8 8 0 0 1.178e+09 2352.26 500931 87380.00 13485
Maximum
Segment
Size (bytes)
1448
the systems above had four 1.6 GHz cores, netperf reports CPU as 0 to 100%
regardless of core count.
and then my systems with the 3.0 GHz cores:
[root@s9 netperf2_trunk]# netperf -H sweb20 -v 2 -t TCP_STREAM -c -C
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to sweb20.cup.hp.com
(16.89.133.20) port 0 AF_INET
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
87380 16384 16384 10.03 941.37 6.40 13.26 2.229 4.615
Alignment Offset Bytes Bytes Sends Bytes Recvs
Local Remote Local Remote Xfered Per Per
Send Recv Send Recv Send (avg) Recv (avg)
8 8 0 0 1.18e+09 16384.06 72035 1453.85 811793
Maximum
Segment
Size (bytes)
1448
[root@s9 netperf2_trunk]# netperf -H sweb20 -v 2 -t TCP_MAERTS -c -C
TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to sweb20.cup.hp.com
(16.89.133.20) port 0 AF_INET
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
87380 16384 16384 10.03 941.35 12.13 5.80 4.221 2.018
Alignment Offset Bytes Bytes Recvs Bytes Sends
Local Remote Local Remote Xfered Per Per
Recv Send Recv Send Recv (avg) Send (avg)
8 8 0 0 1.181e+09 1452.38 812953 16384.00 72065
Maximum
Segment
Size (bytes)
1448
rick jones
^ permalink raw reply
* Re: [IPv6] Fix ICMPv6 redirect handling with target multicast address
From: David Stevens @ 2007-10-02 22:41 UTC (permalink / raw)
To: Brian Haley
Cc: David Miller, netdev@vger.kernel.org, netdev-owner,
YOSHIFUJI Hideaki
In-Reply-To: <4702B2C0.2070004@hp.com>
Brian,
I don't think a few instructions is a performance issue in the
redirect
paths (it'd be pretty broken if you're getting or generating lots of
them), but I
know there are lots of other checks similar to that that will break with
new
attributes, so doing that as a general clean-up separately is ok with me,
too.
With the error message changes, you can add:
Acked-by: David L Stevens <dlstevens@us.ibm.com>
FWIW. :-)
+-DLS
^ permalink raw reply
* Re: tcp bw in 2.6
From: Larry McVoy @ 2007-10-02 22:36 UTC (permalink / raw)
To: David Miller; +Cc: rick.jones2, lm, torvalds, herbert, wscott, netdev
In-Reply-To: <20071002.153216.82129058.davem@davemloft.net>
On Tue, Oct 02, 2007 at 03:32:16PM -0700, David Miller wrote:
> I'm starting to have a theory about what the bad case might
> be.
>
> A strong sender going to an even stronger receiver which can
> pull out packets into the process as fast as they arrive.
> This might be part of what keeps the receive window from
> growing.
I can back you up on that. When I straced the receiving side that goes
slowly, all the reads were short, like 1-2K. The way that works the
reads were a lot larger as I recall.
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
^ permalink raw reply
* Re: [PATCH][TG3]Some cleanups
From: Michael Chan @ 2007-10-02 23:33 UTC (permalink / raw)
To: hadi; +Cc: Matt Carlson, netdev
In-Reply-To: <1191328627.4353.15.camel@localhost>
On Tue, 2007-10-02 at 08:37 -0400, jamal wrote:
> The simplest solution seems to me to modify the definition of
> TG3_SKB_CB
> as i did for e1000 from:
> (struct tg3_tx_cbdata *)&((__skb)->cb[0])
> to:
> (struct tg3_tx_cbdata *)&((__skb)->cb[8])
>
> that way the vlan tags are always present and no need to recreate
> them.
> What do you think?
Seems ok to me. I think we should make it more clear that we're
skipping over the VLAN tag:
(struct tg3_tx_cbdata *)&((__skb)->cb[sizeof(struct vlan_skb_tx_cookie)])
^ permalink raw reply
* Re: tcp bw in 2.6
From: David Miller @ 2007-10-02 22:32 UTC (permalink / raw)
To: rick.jones2; +Cc: lm, torvalds, herbert, wscott, netdev
In-Reply-To: <4702C37F.4030601@hp.com>
From: Rick Jones <rick.jones2@hp.com>
Date: Tue, 02 Oct 2007 15:17:35 -0700
> Stranger still, with a mix of a 2.6.23-rc5ish kernel and a net-2.6.24 one
> (pulled oh middle of last week?) I get link-rate and I see no asymmetry between
> TCP_STREAM and TCP_MAERTS over an "e1000" link with no switch or tg3 with a
> ProCurve on my rx2660's.
>
> I can also run bw_tcp from lmbench 3.0a8 and get 106 MB/s.
>
> I don't have a netgear switch to try in all this...
I'm starting to have a theory about what the bad case might
be.
A strong sender going to an even stronger receiver which can
pull out packets into the process as fast as they arrive.
This might be part of what keeps the receive window from
growing.
^ permalink raw reply
* Re: tcp bw in 2.6
From: Rick Jones @ 2007-10-02 22:17 UTC (permalink / raw)
To: David Miller; +Cc: lm, torvalds, herbert, wscott, netdev
In-Reply-To: <20071002.144709.123999983.davem@davemloft.net>
David Miller wrote:
> From: lm@bitmover.com (Larry McVoy)
> Date: Tue, 2 Oct 2007 14:26:08 -0700
>
>
>>And note that sky2 doesn't have this problem. Does the broadcom do TSO?
>>And sky2 not? I noticed a much higher CPU load for sky2.
>
>
> Yes the broadcoms (the revisions I have) do TSO and it is enabled
> on both sides.
>
> Which makes the mis-matched performance even stranger :)
Stranger still, with a mix of a 2.6.23-rc5ish kernel and a net-2.6.24 one
(pulled oh middle of last week?) I get link-rate and I see no asymmetry between
TCP_STREAM and TCP_MAERTS over an "e1000" link with no switch or tg3 with a
ProCurve on my rx2660's.
I can also run bw_tcp from lmbench 3.0a8 and get 106 MB/s.
I don't have a netgear switch to try in all this...
rick jones
^ permalink raw reply
* Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
From: David Miller @ 2007-10-02 22:04 UTC (permalink / raw)
To: shemminger
Cc: oliver, acme, urs, netdev, kaber, tglx, yoshfuji, ebiederm,
oliver.hartkopp, urs.thuermann
In-Reply-To: <20071002145236.3818bd63@freepuppy.rosehill>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Tue, 2 Oct 2007 14:52:36 -0700
> Please consider using netif_msg_xxx() and module parameter to set
> default message level, like other real network drivers already do.
I keep seeing this recommendation, but the two supposedly most mature
and actively used drivers in the tree, tg3 and e1000 and e1000e, all
do not use this scheme.
In fact there are tons of drivers that even hook up the ethtool
msg_level setting function and never even use the value.
If people aren't using netif_msg_xxx() and the ethtool msg_level
facilities properly, it's because there is a severe dearth of good
example drivers to learn about it from.
^ permalink raw reply
* Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
From: Stephen Hemminger @ 2007-10-02 21:52 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Arnaldo Carvalho de Melo, Urs Thuermann, netdev, David Miller,
Patrick McHardy, Thomas Gleixner, YOSHIFUJI Hideaki,
Eric W. Biederman, Oliver Hartkopp, Oliver Hartkopp,
Urs Thuermann
In-Reply-To: <4702B1FD.70102@hartkopp.net>
On Tue, 02 Oct 2007 23:02:53 +0200
Oliver Hartkopp <oliver@hartkopp.net> wrote:
> Arnaldo Carvalho de Melo wrote:
> > Em Tue, Oct 02, 2007 at 03:10:11PM +0200, Urs Thuermann escreveu:
> >
> >> +
> >> +#ifdef CONFIG_CAN_DEBUG_DEVICES
> >> +static int debug;
> >> +module_param(debug, int, S_IRUGO);
> >> +#endif
> >>
> >
> > Can debug be a boolean? Like its counterpart on DCCP:
> >
> > net/dccp/proto.c:
> >
> > module_param(dccp_debug, bool, 0444);
> >
>
> 'debug' should remain an integer to be able to specifiy debug-levels or
> bit-fields for different Debug outputs.
>
> > Where we also use a namespace prefix, for those of us who use ctags or
> > cscope.
> >
>
> Even if i don't have any general objections to rename this 'debug' to
> 'vcan_debug', it looks like an 'overnamed' module parameter for me. Is
> this a genereal naming scheme recommendation for debug module_params?
>
Please consider using netif_msg_xxx() and module parameter to set
default message level, like other real network drivers already do.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: tcp bw in 2.6
From: Linus Torvalds @ 2007-10-02 21:56 UTC (permalink / raw)
To: Wayne Scott; +Cc: lm, jheffner, herbert, davem, netdev
In-Reply-To: <20071002.164223.59654826.wscott@bitmover.com>
On Tue, 2 Oct 2007, Wayne Scott wrote:
>
> The slow set was done like this:
>
> on ia64: netcat -l -p8888 > /dev/null
> on work: netcat ia64 8888 < /dev/zero
That sounds wrong. Larry claims the slow case is when the side that did
"accept()" does the sending, the above has the listener just reading.
> The fast set was done like this:
>
> on work: netcat -l -p8888 > /dev/null
> on ia64: netcat ia64 8888 < /dev/zero
This one is guaranteed wrong too, since you have the listener reading
(fine), but the sener now doesn't go over the network at all, but sends to
itself.
That said, let's assume that only your description was bogus, the TCP
dumps themselves are ok.
I find the window scaling differences interesting. This is the opening of
the fast sequence from the receiver:
13:35:13.929349 IP 10.3.1.1.ddi-tcp-1 > 10.3.1.10.58415: S 2592471184:2592471184(0) ack 3363219397 win 5792 <mss 1460,sackOK,timestamp 174966955 3714830794,nop,wscale 7>
13:35:13.929702 IP 10.3.1.1.ddi-tcp-1 > 10.3.1.10.58415: . ack 1449 win 68 <nop,nop,timestamp 174966955 3714830795>
13:35:13.929712 IP 10.3.1.1.ddi-tcp-1 > 10.3.1.10.58415: . ack 2897 win 91 <nop,nop,timestamp 174966955 3714830795>
13:35:13.929724 IP 10.3.1.1.ddi-tcp-1 > 10.3.1.10.58415: . ack 4345 win 114 <nop,nop,timestamp 174966955 3714830795>
13:35:13.929941 IP 10.3.1.1.ddi-tcp-1 > 10.3.1.10.58415: . ack 5793 win 136 <nop,nop,timestamp 174966955 3714830795>
13:35:13.929951 IP 10.3.1.1.ddi-tcp-1 > 10.3.1.10.58415: . ack 7241 win 159 <nop,nop,timestamp 174966955 3714830795>
13:35:13.929960 IP 10.3.1.1.ddi-tcp-1 > 10.3.1.10.58415: . ack 8689 win 181 <nop,nop,timestamp 174966955 3714830795>
13:35:13.929970 IP 10.3.1.1.ddi-tcp-1 > 10.3.1.10.58415: . ack 10137 win 204 <nop,nop,timestamp 174966955 3714830795>
13:35:13.929981 IP 10.3.1.1.ddi-tcp-1 > 10.3.1.10.58415: . ack 11585 win 227 <nop,nop,timestamp 174966955 3714830795>
13:35:13.929992 IP 10.3.1.1.ddi-tcp-1 > 10.3.1.10.58415: . ack 13033 win 249 <nop,nop,timestamp 174966955 3714830795>
13:35:13.930331 IP 10.3.1.1.ddi-tcp-1 > 10.3.1.10.58415: . ack 14481 win 272 <nop,nop,timestamp 174966955 3714830795>
...
ie we use a window scale of 7, and we started with a window of 5792 bytes,
and after ten packets it has grown to 272<<7 (34816) bytes.
The slow case is
13:34:16.761034 IP 10.3.1.10.ddi-tcp-1 > 10.3.1.1.49864: S 3299922549:3299922549(0) ack 2548837296 win 5792 <mss 1460,sackOK,timestamp 3714772254 174952667,nop,wscale 2>
13:34:16.761533 IP 10.3.1.10.ddi-tcp-1 > 10.3.1.1.49864: . ack 1449 win 2172 <nop,nop,timestamp 3714772255 174952667>
13:34:16.761553 IP 10.3.1.10.ddi-tcp-1 > 10.3.1.1.49864: . ack 2897 win 2896 <nop,nop,timestamp 3714772255 174952667>
13:34:16.761782 IP 10.3.1.10.ddi-tcp-1 > 10.3.1.1.49864: . ack 4345 win 3620 <nop,nop,timestamp 3714772255 174952667>
13:34:16.761908 IP 10.3.1.10.ddi-tcp-1 > 10.3.1.1.49864: . ack 5793 win 4344 <nop,nop,timestamp 3714772255 174952667>
13:34:16.761916 IP 10.3.1.10.ddi-tcp-1 > 10.3.1.1.49864: . ack 7241 win 5068 <nop,nop,timestamp 3714772255 174952667>
13:34:16.762157 IP 10.3.1.10.ddi-tcp-1 > 10.3.1.1.49864: . ack 8689 win 5792 <nop,nop,timestamp 3714772255 174952667>
13:34:16.762164 IP 10.3.1.10.ddi-tcp-1 > 10.3.1.1.49864: . ack 10137 win 6516 <nop,nop,timestamp 3714772255 174952667>
13:34:16.762283 IP 10.3.1.10.ddi-tcp-1 > 10.3.1.1.49864: . ack 11585 win 7240 <nop,nop,timestamp 3714772256 174952667>
13:34:16.762290 IP 10.3.1.10.ddi-tcp-1 > 10.3.1.1.49864: . ack 13033 win 7964 <nop,nop,timestamp 3714772256 174952667>
13:34:16.762303 IP 10.3.1.10.ddi-tcp-1 > 10.3.1.1.49864: . ack 14481 win 8688 <nop,nop,timestamp 3714772256 174952667>
...
so after the same ten packets, it too has grown to about the same
size (8688<<2 = 34752 bytes).
But the slow case has a smaller window scale, and it actually stops
opening the window at that point: the window stays at 8688<<2 for a long
time (and eventually grows to 9412<<2 and then 16652<<2 in the steady
case, and is basically limited at that 66kB window size).
But the fast one that had a window scale of 7 can keep growing, and will
do so quite aggressively. It grows the window to (1442<<7 = 180kB) in the
first fifty packets.
But in your dump, it doesn't seem to be about who is listening and who is
connecting. It seems to be about the fact that your machine 10.3.1.10 uses
a window scale of 2, while 10.3.1.1 uses a scale of 7.
Linus
^ permalink raw reply
* Re: [patch 05/13] skge: remove broken and unused PHY_M_PC_MDI_XMODE macro
From: Jeff Garzik @ 2007-10-02 21:55 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: akpm, netdev, m.kozlowski
In-Reply-To: <20071002144712.2d3b7ca8@freepuppy.rosehill>
Stephen Hemminger wrote:
> On Tue, 02 Oct 2007 14:11:38 -0700
> akpm@linux-foundation.org wrote:
>
>> From: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
>>
>> Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
>> Cc: Stephen Hemminger <shemminger@linux-foundation.org>
>> Cc: Jeff Garzik <jeff@garzik.org>
>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>> ---
>>
>
> Already in netdev tree isn't it?
Yep.
Jeff
^ permalink raw reply
* Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
From: David Miller @ 2007-10-02 21:50 UTC (permalink / raw)
To: acme
Cc: oliver, urs, netdev, kaber, tglx, yoshfuji, ebiederm,
oliver.hartkopp, urs.thuermann
In-Reply-To: <20071002214325.GB3576@ghostprotocols.net>
From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Date: Tue, 2 Oct 2007 18:43:25 -0300
> I think that helping ctags to find the definition for the debug variable
> to see, for instance, if it is a bitmask or a boolean without having to
> chose from tons of 'debug' variables is a good thing.
I completely agree.
^ permalink raw reply
* Re: [patch 09/13] forcedeth: "no link" is informational
From: Stephen Hemminger @ 2007-10-02 21:49 UTC (permalink / raw)
To: akpm; +Cc: jeff, netdev, akpm, eswierk, aabdulla
In-Reply-To: <200710022111.l92LBf6c022501@imap1.linux-foundation.org>
On Tue, 02 Oct 2007 14:11:41 -0700
akpm@linux-foundation.org wrote:
> From: "Ed Swierk" <eswierk@arastra.com>
>
> Log "no link during initialization" at KERN_INFO as it's not an error, and
> occurs every time the interface comes up (when the forcedeth-phy-power-down
> patch is applied).
>
> Signed-off-by: Ed Swierk <eswierk@arastra.com>
> Cc: Ayaz Abdulla <aabdulla@nvidia.com>
> Cc: Jeff Garzik <jeff@garzik.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> drivers/net/forcedeth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -puN drivers/net/forcedeth.c~forcedeth-no-link-is-informational drivers/net/forcedeth.c
> --- a/drivers/net/forcedeth.c~forcedeth-no-link-is-informational
> +++ a/drivers/net/forcedeth.c
> @@ -4921,7 +4921,7 @@ static int nv_open(struct net_device *de
> if (ret) {
> netif_carrier_on(dev);
> } else {
> - printk("%s: no link during initialization.\n", dev->name);
> + printk(KERN_INFO "%s: no link during initialization.\n", dev->name);
> netif_carrier_off(dev);
> }
> if (oom)
Driver should use netif_msg_link_up()
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
From: Ilpo Järvinen @ 2007-10-02 21:48 UTC (permalink / raw)
To: Cedric Le Goater; +Cc: Andrew Morton, LKML, Netdev, David Miller
In-Reply-To: <Pine.LNX.4.64.0710022303510.26398@kivilampi-30.cs.helsinki.fi>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 250 bytes --]
> On Tue, 2 Oct 2007, Ilpo Järvinen wrote:
>
> > I'm currently out of ideas where it could come from...
Hmm, there seems to be off-by-one in tcp_retrans_try_collapse after
all, or in fact, two of them. I'll post patch for this tomorrow...
--
i.
^ permalink raw reply
* Re: [patch 05/13] skge: remove broken and unused PHY_M_PC_MDI_XMODE macro
From: Stephen Hemminger @ 2007-10-02 21:47 UTC (permalink / raw)
To: akpm; +Cc: jeff, netdev, akpm, m.kozlowski
In-Reply-To: <200710022111.l92LBcbo022488@imap1.linux-foundation.org>
On Tue, 02 Oct 2007 14:11:38 -0700
akpm@linux-foundation.org wrote:
> From: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
>
> Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
> Cc: Stephen Hemminger <shemminger@linux-foundation.org>
> Cc: Jeff Garzik <jeff@garzik.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
Already in netdev tree isn't it?
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: tcp bw in 2.6
From: David Miller @ 2007-10-02 21:47 UTC (permalink / raw)
To: lm; +Cc: torvalds, herbert, wscott, netdev
In-Reply-To: <20071002212608.GG29944@bitmover.com>
From: lm@bitmover.com (Larry McVoy)
Date: Tue, 2 Oct 2007 14:26:08 -0700
> And note that sky2 doesn't have this problem. Does the broadcom do TSO?
> And sky2 not? I noticed a much higher CPU load for sky2.
Yes the broadcoms (the revisions I have) do TSO and it is enabled
on both sides.
Which makes the mis-matched performance even stranger :)
^ permalink raw reply
* Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
From: Arnaldo Carvalho de Melo @ 2007-10-02 21:43 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Urs Thuermann, netdev, David Miller, Patrick McHardy,
Thomas Gleixner, YOSHIFUJI Hideaki, Eric W. Biederman,
Oliver Hartkopp, Urs Thuermann
In-Reply-To: <4702B1FD.70102@hartkopp.net>
Em Tue, Oct 02, 2007 at 11:02:53PM +0200, Oliver Hartkopp escreveu:
> Arnaldo Carvalho de Melo wrote:
>> Em Tue, Oct 02, 2007 at 03:10:11PM +0200, Urs Thuermann escreveu:
>>
>>> +
>>> +#ifdef CONFIG_CAN_DEBUG_DEVICES
>>> +static int debug;
>>> +module_param(debug, int, S_IRUGO);
>>> +#endif
>>>
>>
>> Can debug be a boolean? Like its counterpart on DCCP:
>>
>> net/dccp/proto.c:
>>
>> module_param(dccp_debug, bool, 0444);
>>
>
> 'debug' should remain an integer to be able to specifiy debug-levels or
> bit-fields for different Debug outputs.
>
>> Where we also use a namespace prefix, for those of us who use ctags or
>> cscope.
>>
>
> Even if i don't have any general objections to rename this 'debug' to
> 'vcan_debug', it looks like an 'overnamed' module parameter for me. Is this
> a genereal naming scheme recommendation for debug module_params?
[acme@mica linux-2.6.23-rc9-rt1]$ find . -name "*.c" | xargs grep
'module_param(.\+debug,' | wc -l
112
[acme@mica linux-2.6.23-rc9-rt1]$ find . -name "*.c" | xargs grep
'module_param(debug,' | wc -l
233
[acme@mica linux-2.6.23-rc9-rt1]$
I think that helping ctags to find the definition for the debug variable
to see, for instance, if it is a bitmask or a boolean without having to
chose from tons of 'debug' variables is a good thing.
- Arnaldo
^ permalink raw reply
* Re: tcp bw in 2.6
From: David Miller @ 2007-10-02 21:32 UTC (permalink / raw)
To: lm; +Cc: rick.jones2, torvalds, wscott, netdev
In-Reply-To: <20071002184032.GB29944@bitmover.com>
From: lm@bitmover.com (Larry McVoy)
Date: Tue, 2 Oct 2007 11:40:32 -0700
> I doubt it, the same test works fine in one direction and poorly in the other.
> Wouldn't the flow control squelch either way?
HW controls for these things are typically:
1) Generates flow control flames
2) Listens for them
So you can have flow control operational in one direction
and not the other.
^ permalink raw reply
* Re: tcp bw in 2.6
From: Larry McVoy @ 2007-10-02 21:26 UTC (permalink / raw)
To: David Miller; +Cc: lm, torvalds, herbert, wscott, netdev
In-Reply-To: <20071002.141656.42880006.davem@davemloft.net>
On Tue, Oct 02, 2007 at 02:16:56PM -0700, David Miller wrote:
> We absolutely depend upon people like you to report when there are
> anomalies like this. It's the only thing that scales.
Well cool, finally doing something useful :)
Is this issue no test setup? Because this does seem like something we'd
want to have work well.
> FWIW I have a t1000 Niagara box and an Ultra45 going through a netgear
> gigabit switch. I'm getting 85MB/sec in one direction and 10MB/sec in
> the other (using bw_tcp from lmbench3).
Note that bw_tcp mucks with SND/RCVBUF. It probably shouldn't, it's been
12 years since that code went in there and I dunno if it is still needed.
> Both are using identical
> broadcom tigon3 gigabit chips and identical current kernels so that is
> a truly strange result.
>
> I'll investigate, it may be the same thing you're seeing.
Wow, sounds very similar. In my case I was seeing pretty close to 3x
consistently. You're more like 8x, but I was all e1000 not broadcom.
And note that sky2 doesn't have this problem. Does the broadcom do TSO?
And sky2 not? I noticed a much higher CPU load for sky2.
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
^ permalink raw reply
* [PATCH] [11/11] pasemi_mac: enable iommu support
From: Olof Johansson @ 2007-10-02 21:28 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
In-Reply-To: <20071002212421.GA2282@lixom.net>
pasemi_mac: use buffer index pointer in clean_rx()
Use the new features in B0 for buffer ring index on the receive side. This
means we no longer have to search in the ring for where the buffer
came from.
Also cleanup the RX cleaning side a little, while I was at it.
Note: Pre-B0 hardware is no longer supported, and needs a pile of other
workarounds that are not being submitted for mainline inclusion. So the
fact that this breaks old hardware is not a problem at this time.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: k.org/drivers/net/pasemi_mac.c
===================================================================
--- k.org.orig/drivers/net/pasemi_mac.c
+++ k.org/drivers/net/pasemi_mac.c
@@ -243,9 +243,9 @@ static int pasemi_mac_setup_rx_resources
PAS_DMA_RXINT_BASEU_SIZ(RX_RING_SIZE >> 3));
write_dma_reg(mac, PAS_DMA_RXINT_CFG(mac->dma_if),
- PAS_DMA_RXINT_CFG_DHL(3) |
- PAS_DMA_RXINT_CFG_L2 |
- PAS_DMA_RXINT_CFG_LW);
+ PAS_DMA_RXINT_CFG_DHL(3) | PAS_DMA_RXINT_CFG_L2 |
+ PAS_DMA_RXINT_CFG_LW | PAS_DMA_RXINT_CFG_RBP |
+ PAS_DMA_RXINT_CFG_HEN);
ring->next_to_fill = 0;
ring->next_to_clean = 0;
@@ -402,13 +402,12 @@ static void pasemi_mac_free_rx_resources
static void pasemi_mac_replenish_rx_ring(struct net_device *dev, int limit)
{
struct pasemi_mac *mac = netdev_priv(dev);
- int start = mac->rx->next_to_fill;
- unsigned int fill, count;
+ int fill, count;
if (limit <= 0)
return;
- fill = start;
+ fill = mac->rx->next_to_fill;
for (count = 0; count < limit; count++) {
struct pasemi_mac_buffer *info = &RX_RING_INFO(mac, fill);
u64 *buff = &RX_BUFF(mac, fill);
@@ -446,10 +445,10 @@ static void pasemi_mac_replenish_rx_ring
wmb();
- write_dma_reg(mac, PAS_DMA_RXCHAN_INCR(mac->dma_rxch), count);
write_dma_reg(mac, PAS_DMA_RXINT_INCR(mac->dma_if), count);
- mac->rx->next_to_fill += count;
+ mac->rx->next_to_fill = (mac->rx->next_to_fill + count) &
+ (RX_RING_SIZE - 1);
}
static void pasemi_mac_restart_rx_intr(struct pasemi_mac *mac)
@@ -517,15 +516,19 @@ static int pasemi_mac_clean_rx(struct pa
int count;
struct pasemi_mac_buffer *info;
struct sk_buff *skb;
- unsigned int i, len;
+ unsigned int len;
u64 macrx;
dma_addr_t dma;
+ int buf_index;
+ u64 eval;
spin_lock(&mac->rx->lock);
n = mac->rx->next_to_clean;
- for (count = limit; count; count--) {
+ prefetch(RX_RING(mac, n));
+
+ for (count = 0; count < limit; count++) {
macrx = RX_RING(mac, n);
if ((macrx & XCT_MACRX_E) ||
@@ -537,21 +540,14 @@ static int pasemi_mac_clean_rx(struct pa
info = NULL;
- /* We have to scan for our skb since there's no way
- * to back-map them from the descriptor, and if we
- * have several receive channels then they might not
- * show up in the same order as they were put on the
- * interface ring.
- */
+ BUG_ON(!(macrx & XCT_MACRX_RR_8BRES));
- dma = (RX_RING(mac, n+1) & XCT_PTR_ADDR_M);
- for (i = mac->rx->next_to_fill;
- i < (mac->rx->next_to_fill + RX_RING_SIZE);
- i++) {
- info = &RX_RING_INFO(mac, i);
- if (info->dma == dma)
- break;
- }
+ eval = (RX_RING(mac, n+1) & XCT_RXRES_8B_EVAL_M) >>
+ XCT_RXRES_8B_EVAL_S;
+ buf_index = eval-1;
+
+ dma = (RX_RING(mac, n+2) & XCT_PTR_ADDR_M);
+ info = &RX_RING_INFO(mac, buf_index);
skb = info->skb;
@@ -600,9 +596,9 @@ static int pasemi_mac_clean_rx(struct pa
/* Need to zero it out since hardware doesn't, since the
* replenish loop uses it to tell when it's done.
*/
- RX_BUFF(mac, i) = 0;
+ RX_BUFF(mac, buf_index) = 0;
- n += 2;
+ n += 4;
}
if (n > RX_RING_SIZE) {
@@ -610,8 +606,16 @@ static int pasemi_mac_clean_rx(struct pa
write_iob_reg(mac, PAS_IOB_COM_PKTHDRCNT, 0);
n &= (RX_RING_SIZE-1);
}
+
mac->rx->next_to_clean = n;
- pasemi_mac_replenish_rx_ring(mac->netdev, limit-count);
+
+ /* Increase is in number of 16-byte entries, and since each descriptor
+ * with an 8BRES takes up 3x8 bytes (padded to 4x8), increase with
+ * count*2.
+ */
+ write_dma_reg(mac, PAS_DMA_RXCHAN_INCR(mac->dma_rxch), count << 1);
+
+ pasemi_mac_replenish_rx_ring(mac->netdev, count);
spin_unlock(&mac->rx->lock);
@@ -927,6 +931,8 @@ static int pasemi_mac_open(struct net_de
pasemi_mac_replenish_rx_ring(dev, RX_RING_SIZE);
+ write_dma_reg(mac, PAS_DMA_RXCHAN_INCR(mac->dma_rxch), RX_RING_SIZE>>1);
+
flags = PAS_MAC_CFG_PCFG_S1 | PAS_MAC_CFG_PCFG_PE |
PAS_MAC_CFG_PCFG_PR | PAS_MAC_CFG_PCFG_CE;
Index: k.org/drivers/net/pasemi_mac.h
===================================================================
--- k.org.orig/drivers/net/pasemi_mac.h
+++ k.org/drivers/net/pasemi_mac.h
@@ -206,12 +206,15 @@ enum {
#define PAS_DMA_RXINT_RCMDSTA_DROPS_M 0xfffe0000
#define PAS_DMA_RXINT_RCMDSTA_DROPS_S 17
#define PAS_DMA_RXINT_CFG(i) (0x204+(i)*_PAS_DMA_RXINT_STRIDE)
+#define PAS_DMA_RXINT_CFG_RBP 0x80000000
+#define PAS_DMA_RXINT_CFG_ITRR 0x40000000
#define PAS_DMA_RXINT_CFG_DHL_M 0x07000000
#define PAS_DMA_RXINT_CFG_DHL_S 24
#define PAS_DMA_RXINT_CFG_DHL(x) (((x) << PAS_DMA_RXINT_CFG_DHL_S) & \
PAS_DMA_RXINT_CFG_DHL_M)
#define PAS_DMA_RXINT_CFG_LW 0x00200000
#define PAS_DMA_RXINT_CFG_L2 0x00100000
+#define PAS_DMA_RXINT_CFG_HEN 0x00080000
#define PAS_DMA_RXINT_CFG_WIF 0x00000002
#define PAS_DMA_RXINT_CFG_WIL 0x00000001
@@ -425,10 +428,9 @@ enum {
/* Receive descriptor fields */
#define XCT_MACRX_T 0x8000000000000000ull
#define XCT_MACRX_ST 0x4000000000000000ull
-#define XCT_MACRX_NORES 0x0000000000000000ull
-#define XCT_MACRX_8BRES 0x1000000000000000ull
-#define XCT_MACRX_24BRES 0x2000000000000000ull
-#define XCT_MACRX_40BRES 0x3000000000000000ull
+#define XCT_MACRX_RR_M 0x3000000000000000ull
+#define XCT_MACRX_RR_NORES 0x0000000000000000ull
+#define XCT_MACRX_RR_8BRES 0x1000000000000000ull
#define XCT_MACRX_O 0x0400000000000000ull
#define XCT_MACRX_E 0x0200000000000000ull
#define XCT_MACRX_FF 0x0100000000000000ull
@@ -476,6 +478,17 @@ enum {
#define XCT_PTR_ADDR(x) ((((long)(x)) << XCT_PTR_ADDR_S) & \
XCT_PTR_ADDR_M)
+/* Receive interface 8byte result fields */
+#define XCT_RXRES_8B_L4O_M 0xff00000000000000ull
+#define XCT_RXRES_8B_L4O_S 56
+#define XCT_RXRES_8B_RULE_M 0x00ffff0000000000ull
+#define XCT_RXRES_8B_RULE_S 40
+#define XCT_RXRES_8B_EVAL_M 0x000000ffff000000ull
+#define XCT_RXRES_8B_EVAL_S 24
+#define XCT_RXRES_8B_HTYPE_M 0x0000000000f00000ull
+#define XCT_RXRES_8B_HASH_M 0x00000000000fffffull
+#define XCT_RXRES_8B_HASH_S 0
+
/* Receive interface buffer fields */
#define XCT_RXB_LEN_M 0x0ffff00000000000ull
#define XCT_RXB_LEN_S 44
^ permalink raw reply
* [PATCH] [10/11] pasemi_mac: use buffer index pointer in clean_rx()
From: Olof Johansson @ 2007-10-02 21:27 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
In-Reply-To: <20071002212421.GA2282@lixom.net>
pasemi_mac: use buffer index pointer in clean_rx()
Use the new features in B0 for buffer ring index on the receive side. This
means we no longer have to search in the ring for where the buffer
came from.
Also cleanup the RX cleaning side a little, while I was at it.
Note: Pre-B0 hardware is no longer supported, and needs a pile of other
workarounds that are not being submitted for mainline inclusion. So the
fact that this breaks old hardware is not a problem at this time.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: k.org/drivers/net/pasemi_mac.c
===================================================================
--- k.org.orig/drivers/net/pasemi_mac.c
+++ k.org/drivers/net/pasemi_mac.c
@@ -243,9 +243,9 @@ static int pasemi_mac_setup_rx_resources
PAS_DMA_RXINT_BASEU_SIZ(RX_RING_SIZE >> 3));
write_dma_reg(mac, PAS_DMA_RXINT_CFG(mac->dma_if),
- PAS_DMA_RXINT_CFG_DHL(3) |
- PAS_DMA_RXINT_CFG_L2 |
- PAS_DMA_RXINT_CFG_LW);
+ PAS_DMA_RXINT_CFG_DHL(3) | PAS_DMA_RXINT_CFG_L2 |
+ PAS_DMA_RXINT_CFG_LW | PAS_DMA_RXINT_CFG_RBP |
+ PAS_DMA_RXINT_CFG_HEN);
ring->next_to_fill = 0;
ring->next_to_clean = 0;
@@ -402,13 +402,12 @@ static void pasemi_mac_free_rx_resources
static void pasemi_mac_replenish_rx_ring(struct net_device *dev, int limit)
{
struct pasemi_mac *mac = netdev_priv(dev);
- int start = mac->rx->next_to_fill;
- unsigned int fill, count;
+ int fill, count;
if (limit <= 0)
return;
- fill = start;
+ fill = mac->rx->next_to_fill;
for (count = 0; count < limit; count++) {
struct pasemi_mac_buffer *info = &RX_RING_INFO(mac, fill);
u64 *buff = &RX_BUFF(mac, fill);
@@ -446,10 +445,10 @@ static void pasemi_mac_replenish_rx_ring
wmb();
- write_dma_reg(mac, PAS_DMA_RXCHAN_INCR(mac->dma_rxch), count);
write_dma_reg(mac, PAS_DMA_RXINT_INCR(mac->dma_if), count);
- mac->rx->next_to_fill += count;
+ mac->rx->next_to_fill = (mac->rx->next_to_fill + count) &
+ (RX_RING_SIZE - 1);
}
static void pasemi_mac_restart_rx_intr(struct pasemi_mac *mac)
@@ -517,15 +516,19 @@ static int pasemi_mac_clean_rx(struct pa
int count;
struct pasemi_mac_buffer *info;
struct sk_buff *skb;
- unsigned int i, len;
+ unsigned int len;
u64 macrx;
dma_addr_t dma;
+ int buf_index;
+ u64 eval;
spin_lock(&mac->rx->lock);
n = mac->rx->next_to_clean;
- for (count = limit; count; count--) {
+ prefetch(RX_RING(mac, n));
+
+ for (count = 0; count < limit; count++) {
macrx = RX_RING(mac, n);
if ((macrx & XCT_MACRX_E) ||
@@ -537,21 +540,14 @@ static int pasemi_mac_clean_rx(struct pa
info = NULL;
- /* We have to scan for our skb since there's no way
- * to back-map them from the descriptor, and if we
- * have several receive channels then they might not
- * show up in the same order as they were put on the
- * interface ring.
- */
+ BUG_ON(!(macrx & XCT_MACRX_RR_8BRES));
- dma = (RX_RING(mac, n+1) & XCT_PTR_ADDR_M);
- for (i = mac->rx->next_to_fill;
- i < (mac->rx->next_to_fill + RX_RING_SIZE);
- i++) {
- info = &RX_RING_INFO(mac, i);
- if (info->dma == dma)
- break;
- }
+ eval = (RX_RING(mac, n+1) & XCT_RXRES_8B_EVAL_M) >>
+ XCT_RXRES_8B_EVAL_S;
+ buf_index = eval-1;
+
+ dma = (RX_RING(mac, n+2) & XCT_PTR_ADDR_M);
+ info = &RX_RING_INFO(mac, buf_index);
skb = info->skb;
@@ -600,9 +596,9 @@ static int pasemi_mac_clean_rx(struct pa
/* Need to zero it out since hardware doesn't, since the
* replenish loop uses it to tell when it's done.
*/
- RX_BUFF(mac, i) = 0;
+ RX_BUFF(mac, buf_index) = 0;
- n += 2;
+ n += 4;
}
if (n > RX_RING_SIZE) {
@@ -610,8 +606,16 @@ static int pasemi_mac_clean_rx(struct pa
write_iob_reg(mac, PAS_IOB_COM_PKTHDRCNT, 0);
n &= (RX_RING_SIZE-1);
}
+
mac->rx->next_to_clean = n;
- pasemi_mac_replenish_rx_ring(mac->netdev, limit-count);
+
+ /* Increase is in number of 16-byte entries, and since each descriptor
+ * with an 8BRES takes up 3x8 bytes (padded to 4x8), increase with
+ * count*2.
+ */
+ write_dma_reg(mac, PAS_DMA_RXCHAN_INCR(mac->dma_rxch), count << 1);
+
+ pasemi_mac_replenish_rx_ring(mac->netdev, count);
spin_unlock(&mac->rx->lock);
@@ -927,6 +931,8 @@ static int pasemi_mac_open(struct net_de
pasemi_mac_replenish_rx_ring(dev, RX_RING_SIZE);
+ write_dma_reg(mac, PAS_DMA_RXCHAN_INCR(mac->dma_rxch), RX_RING_SIZE>>1);
+
flags = PAS_MAC_CFG_PCFG_S1 | PAS_MAC_CFG_PCFG_PE |
PAS_MAC_CFG_PCFG_PR | PAS_MAC_CFG_PCFG_CE;
Index: k.org/drivers/net/pasemi_mac.h
===================================================================
--- k.org.orig/drivers/net/pasemi_mac.h
+++ k.org/drivers/net/pasemi_mac.h
@@ -206,12 +206,15 @@ enum {
#define PAS_DMA_RXINT_RCMDSTA_DROPS_M 0xfffe0000
#define PAS_DMA_RXINT_RCMDSTA_DROPS_S 17
#define PAS_DMA_RXINT_CFG(i) (0x204+(i)*_PAS_DMA_RXINT_STRIDE)
+#define PAS_DMA_RXINT_CFG_RBP 0x80000000
+#define PAS_DMA_RXINT_CFG_ITRR 0x40000000
#define PAS_DMA_RXINT_CFG_DHL_M 0x07000000
#define PAS_DMA_RXINT_CFG_DHL_S 24
#define PAS_DMA_RXINT_CFG_DHL(x) (((x) << PAS_DMA_RXINT_CFG_DHL_S) & \
PAS_DMA_RXINT_CFG_DHL_M)
#define PAS_DMA_RXINT_CFG_LW 0x00200000
#define PAS_DMA_RXINT_CFG_L2 0x00100000
+#define PAS_DMA_RXINT_CFG_HEN 0x00080000
#define PAS_DMA_RXINT_CFG_WIF 0x00000002
#define PAS_DMA_RXINT_CFG_WIL 0x00000001
@@ -425,10 +428,9 @@ enum {
/* Receive descriptor fields */
#define XCT_MACRX_T 0x8000000000000000ull
#define XCT_MACRX_ST 0x4000000000000000ull
-#define XCT_MACRX_NORES 0x0000000000000000ull
-#define XCT_MACRX_8BRES 0x1000000000000000ull
-#define XCT_MACRX_24BRES 0x2000000000000000ull
-#define XCT_MACRX_40BRES 0x3000000000000000ull
+#define XCT_MACRX_RR_M 0x3000000000000000ull
+#define XCT_MACRX_RR_NORES 0x0000000000000000ull
+#define XCT_MACRX_RR_8BRES 0x1000000000000000ull
#define XCT_MACRX_O 0x0400000000000000ull
#define XCT_MACRX_E 0x0200000000000000ull
#define XCT_MACRX_FF 0x0100000000000000ull
@@ -476,6 +478,17 @@ enum {
#define XCT_PTR_ADDR(x) ((((long)(x)) << XCT_PTR_ADDR_S) & \
XCT_PTR_ADDR_M)
+/* Receive interface 8byte result fields */
+#define XCT_RXRES_8B_L4O_M 0xff00000000000000ull
+#define XCT_RXRES_8B_L4O_S 56
+#define XCT_RXRES_8B_RULE_M 0x00ffff0000000000ull
+#define XCT_RXRES_8B_RULE_S 40
+#define XCT_RXRES_8B_EVAL_M 0x000000ffff000000ull
+#define XCT_RXRES_8B_EVAL_S 24
+#define XCT_RXRES_8B_HTYPE_M 0x0000000000f00000ull
+#define XCT_RXRES_8B_HASH_M 0x00000000000fffffull
+#define XCT_RXRES_8B_HASH_S 0
+
/* Receive interface buffer fields */
#define XCT_RXB_LEN_M 0x0ffff00000000000ull
#define XCT_RXB_LEN_S 44
^ permalink raw reply
* [PATCH] [9/11] pasemi_mac: clear out old errors on interface open
From: Olof Johansson @ 2007-10-02 21:27 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
In-Reply-To: <20071002212421.GA2282@lixom.net>
pasemi_mac: clear out old errors on interface open
Clear out any pending errors when an interface is brought up. Since the bits
are sticky, they might be from interface shutdown time after firmware has
used it, etc.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: k.org/drivers/net/pasemi_mac.c
===================================================================
--- k.org.orig/drivers/net/pasemi_mac.c
+++ k.org/drivers/net/pasemi_mac.c
@@ -903,16 +903,27 @@ static int pasemi_mac_open(struct net_de
/* enable rx if */
write_dma_reg(mac, PAS_DMA_RXINT_RCMDSTA(mac->dma_if),
- PAS_DMA_RXINT_RCMDSTA_EN);
+ PAS_DMA_RXINT_RCMDSTA_EN |
+ PAS_DMA_RXINT_RCMDSTA_DROPS_M |
+ PAS_DMA_RXINT_RCMDSTA_BP |
+ PAS_DMA_RXINT_RCMDSTA_OO |
+ PAS_DMA_RXINT_RCMDSTA_BT);
/* enable rx channel */
write_dma_reg(mac, PAS_DMA_RXCHAN_CCMDSTA(mac->dma_rxch),
PAS_DMA_RXCHAN_CCMDSTA_EN |
- PAS_DMA_RXCHAN_CCMDSTA_DU);
+ PAS_DMA_RXCHAN_CCMDSTA_DU |
+ PAS_DMA_RXCHAN_CCMDSTA_OD |
+ PAS_DMA_RXCHAN_CCMDSTA_FD |
+ PAS_DMA_RXCHAN_CCMDSTA_DT);
/* enable tx channel */
write_dma_reg(mac, PAS_DMA_TXCHAN_TCMDSTA(mac->dma_txch),
- PAS_DMA_TXCHAN_TCMDSTA_EN);
+ PAS_DMA_TXCHAN_TCMDSTA_EN |
+ PAS_DMA_TXCHAN_TCMDSTA_SZ |
+ PAS_DMA_TXCHAN_TCMDSTA_DB |
+ PAS_DMA_TXCHAN_TCMDSTA_DE |
+ PAS_DMA_TXCHAN_TCMDSTA_DA);
pasemi_mac_replenish_rx_ring(dev, RX_RING_SIZE);
@@ -987,7 +998,7 @@ out_rx_resources:
static int pasemi_mac_close(struct net_device *dev)
{
struct pasemi_mac *mac = netdev_priv(dev);
- unsigned int stat;
+ unsigned int sta;
int retries;
if (mac->phydev) {
@@ -998,6 +1009,26 @@ static int pasemi_mac_close(struct net_d
netif_stop_queue(dev);
napi_disable(&mac->napi);
+ sta = read_dma_reg(mac, PAS_DMA_RXINT_RCMDSTA(mac->dma_if));
+ if (sta & (PAS_DMA_RXINT_RCMDSTA_BP |
+ PAS_DMA_RXINT_RCMDSTA_OO |
+ PAS_DMA_RXINT_RCMDSTA_BT))
+ printk(KERN_DEBUG "pasemi_mac: rcmdsta error: 0x%08x\n", sta);
+
+ sta = read_dma_reg(mac, PAS_DMA_RXCHAN_CCMDSTA(mac->dma_rxch));
+ if (sta & (PAS_DMA_RXCHAN_CCMDSTA_DU |
+ PAS_DMA_RXCHAN_CCMDSTA_OD |
+ PAS_DMA_RXCHAN_CCMDSTA_FD |
+ PAS_DMA_RXCHAN_CCMDSTA_DT))
+ printk(KERN_DEBUG "pasemi_mac: ccmdsta error: 0x%08x\n", sta);
+
+ sta = read_dma_reg(mac, PAS_DMA_TXCHAN_TCMDSTA(mac->dma_txch));
+ if (sta & (PAS_DMA_TXCHAN_TCMDSTA_SZ |
+ PAS_DMA_TXCHAN_TCMDSTA_DB |
+ PAS_DMA_TXCHAN_TCMDSTA_DE |
+ PAS_DMA_TXCHAN_TCMDSTA_DA))
+ printk(KERN_DEBUG "pasemi_mac: tcmdsta error: 0x%08x\n", sta);
+
/* Clean out any pending buffers */
pasemi_mac_clean_tx(mac);
pasemi_mac_clean_rx(mac, RX_RING_SIZE);
@@ -1008,33 +1039,33 @@ static int pasemi_mac_close(struct net_d
write_dma_reg(mac, PAS_DMA_RXCHAN_CCMDSTA(mac->dma_rxch), PAS_DMA_RXCHAN_CCMDSTA_ST);
for (retries = 0; retries < MAX_RETRIES; retries++) {
- stat = read_dma_reg(mac, PAS_DMA_TXCHAN_TCMDSTA(mac->dma_txch));
- if (!(stat & PAS_DMA_TXCHAN_TCMDSTA_ACT))
+ sta = read_dma_reg(mac, PAS_DMA_TXCHAN_TCMDSTA(mac->dma_txch));
+ if (!(sta & PAS_DMA_TXCHAN_TCMDSTA_ACT))
break;
cond_resched();
}
- if (stat & PAS_DMA_TXCHAN_TCMDSTA_ACT)
+ if (sta & PAS_DMA_TXCHAN_TCMDSTA_ACT)
dev_err(&mac->dma_pdev->dev, "Failed to stop tx channel\n");
for (retries = 0; retries < MAX_RETRIES; retries++) {
- stat = read_dma_reg(mac, PAS_DMA_RXCHAN_CCMDSTA(mac->dma_rxch));
- if (!(stat & PAS_DMA_RXCHAN_CCMDSTA_ACT))
+ sta = read_dma_reg(mac, PAS_DMA_RXCHAN_CCMDSTA(mac->dma_rxch));
+ if (!(sta & PAS_DMA_RXCHAN_CCMDSTA_ACT))
break;
cond_resched();
}
- if (stat & PAS_DMA_RXCHAN_CCMDSTA_ACT)
+ if (sta & PAS_DMA_RXCHAN_CCMDSTA_ACT)
dev_err(&mac->dma_pdev->dev, "Failed to stop rx channel\n");
for (retries = 0; retries < MAX_RETRIES; retries++) {
- stat = read_dma_reg(mac, PAS_DMA_RXINT_RCMDSTA(mac->dma_if));
- if (!(stat & PAS_DMA_RXINT_RCMDSTA_ACT))
+ sta = read_dma_reg(mac, PAS_DMA_RXINT_RCMDSTA(mac->dma_if));
+ if (!(sta & PAS_DMA_RXINT_RCMDSTA_ACT))
break;
cond_resched();
}
- if (stat & PAS_DMA_RXINT_RCMDSTA_ACT)
+ if (sta & PAS_DMA_RXINT_RCMDSTA_ACT)
dev_err(&mac->dma_pdev->dev, "Failed to stop rx interface\n");
/* Then, disable the channel. This must be done separately from
Index: k.org/drivers/net/pasemi_mac.h
===================================================================
--- k.org.orig/drivers/net/pasemi_mac.h
+++ k.org/drivers/net/pasemi_mac.h
@@ -241,6 +241,10 @@ enum {
#define PAS_DMA_TXCHAN_TCMDSTA_EN 0x00000001 /* Enabled */
#define PAS_DMA_TXCHAN_TCMDSTA_ST 0x00000002 /* Stop interface */
#define PAS_DMA_TXCHAN_TCMDSTA_ACT 0x00010000 /* Active */
+#define PAS_DMA_TXCHAN_TCMDSTA_SZ 0x00000800
+#define PAS_DMA_TXCHAN_TCMDSTA_DB 0x00000400
+#define PAS_DMA_TXCHAN_TCMDSTA_DE 0x00000200
+#define PAS_DMA_TXCHAN_TCMDSTA_DA 0x00000100
#define PAS_DMA_TXCHAN_CFG(c) (0x304+(c)*_PAS_DMA_TXCHAN_STRIDE)
#define PAS_DMA_TXCHAN_CFG_TY_IFACE 0x00000000 /* Type = interface */
#define PAS_DMA_TXCHAN_CFG_TATTR_M 0x0000003c
@@ -283,6 +287,9 @@ enum {
#define PAS_DMA_RXCHAN_CCMDSTA_ST 0x00000002 /* Stop interface */
#define PAS_DMA_RXCHAN_CCMDSTA_ACT 0x00010000 /* Active */
#define PAS_DMA_RXCHAN_CCMDSTA_DU 0x00020000
+#define PAS_DMA_RXCHAN_CCMDSTA_OD 0x00002000
+#define PAS_DMA_RXCHAN_CCMDSTA_FD 0x00001000
+#define PAS_DMA_RXCHAN_CCMDSTA_DT 0x00000800
#define PAS_DMA_RXCHAN_CFG(c) (0x804+(c)*_PAS_DMA_RXCHAN_STRIDE)
#define PAS_DMA_RXCHAN_CFG_HBU_M 0x00000380
#define PAS_DMA_RXCHAN_CFG_HBU_S 7
^ permalink raw reply
* [PATCH] [8/11] pasemi_mac: update todo list
From: Olof Johansson @ 2007-10-02 21:27 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
In-Reply-To: <20071002212421.GA2282@lixom.net>
pasemi_mac: update todo list
Remove some stale todo items that have been taken care of. Add a couple
of upcoming ones.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: 2.6.23/drivers/net/pasemi_mac.c
===================================================================
--- 2.6.23.orig/drivers/net/pasemi_mac.c
+++ 2.6.23/drivers/net/pasemi_mac.c
@@ -46,12 +46,10 @@
/* TODO list
*
- * - Get rid of pci_{read,write}_config(), map registers with ioremap
- * for performance
- * - PHY support
* - Multicast support
* - Large MTU support
- * - Other performance improvements
+ * - SW LRO
+ * - Multiqueue RX/TX
*/
^ permalink raw reply
* [PATCH] [7/11] pasemi_mac: further performance tweaks
From: Olof Johansson @ 2007-10-02 21:27 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
In-Reply-To: <20071002212421.GA2282@lixom.net>
pasemi_mac: further performance tweaks
Misc driver tweaks for pasemi_mac:
* Increase ring size (really needed mostly on 10G)
* Take out an unneeded barrier
* Move around a few prefetches and reorder a few calls
* Don't try to clean on full tx buffer, just let things
take their course and stop the queue directly
* Avoid filling on the same line as the interface is
working on to reduce cache line bouncing
* Avoid unneeded clearing of software state (and make the
interface shutdown code handle it)
* Fix up some of the tx ring wrap logic.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: k.org/drivers/net/pasemi_mac.c
===================================================================
--- k.org.orig/drivers/net/pasemi_mac.c
+++ k.org/drivers/net/pasemi_mac.c
@@ -56,8 +56,8 @@
/* Must be a power of two */
-#define RX_RING_SIZE 512
-#define TX_RING_SIZE 512
+#define RX_RING_SIZE 4096
+#define TX_RING_SIZE 4096
#define DEFAULT_MSG_ENABLE \
(NETIF_MSG_DRV | \
@@ -336,8 +336,16 @@ static void pasemi_mac_free_tx_resources
struct pasemi_mac_buffer *info;
dma_addr_t dmas[MAX_SKB_FRAGS+1];
int freed;
+ int start, limit;
- for (i = 0; i < TX_RING_SIZE; i += freed) {
+ start = mac->tx->next_to_clean;
+ limit = mac->tx->next_to_fill;
+
+ /* Compensate for when fill has wrapped and clean has not */
+ if (start > limit)
+ limit += TX_RING_SIZE;
+
+ for (i = start; i < limit; i += freed) {
info = &TX_RING_INFO(mac, i+1);
if (info->dma && info->skb) {
for (j = 0; j <= skb_shinfo(info->skb)->nr_frags; j++)
@@ -520,9 +528,6 @@ static int pasemi_mac_clean_rx(struct pa
n = mac->rx->next_to_clean;
for (count = limit; count; count--) {
-
- rmb();
-
macrx = RX_RING(mac, n);
if ((macrx & XCT_MACRX_E) ||
@@ -550,14 +555,10 @@ static int pasemi_mac_clean_rx(struct pa
break;
}
- prefetchw(info);
-
skb = info->skb;
- prefetchw(skb);
- info->dma = 0;
- pci_unmap_single(mac->dma_pdev, dma, skb->len,
- PCI_DMA_FROMDEVICE);
+ prefetch(skb);
+ prefetch(&skb->data_len);
len = (macrx & XCT_MACRX_LLEN_M) >> XCT_MACRX_LLEN_S;
@@ -576,10 +577,9 @@ static int pasemi_mac_clean_rx(struct pa
} else
info->skb = NULL;
- /* Need to zero it out since hardware doesn't, since the
- * replenish loop uses it to tell when it's done.
- */
- RX_BUFF(mac, i) = 0;
+ pci_unmap_single(mac->dma_pdev, dma, len, PCI_DMA_FROMDEVICE);
+
+ info->dma = 0;
skb_put(skb, len);
@@ -599,6 +599,11 @@ static int pasemi_mac_clean_rx(struct pa
RX_RING(mac, n) = 0;
RX_RING(mac, n+1) = 0;
+ /* Need to zero it out since hardware doesn't, since the
+ * replenish loop uses it to tell when it's done.
+ */
+ RX_BUFF(mac, i) = 0;
+
n += 2;
}
@@ -621,27 +626,33 @@ static int pasemi_mac_clean_rx(struct pa
static int pasemi_mac_clean_tx(struct pasemi_mac *mac)
{
int i, j;
- struct pasemi_mac_buffer *info;
- unsigned int start, descr_count, buf_count, limit;
+ unsigned int start, descr_count, buf_count, batch_limit;
+ unsigned int ring_limit;
unsigned int total_count;
unsigned long flags;
struct sk_buff *skbs[TX_CLEAN_BATCHSIZE];
dma_addr_t dmas[TX_CLEAN_BATCHSIZE][MAX_SKB_FRAGS+1];
total_count = 0;
- limit = TX_CLEAN_BATCHSIZE;
+ batch_limit = TX_CLEAN_BATCHSIZE;
restart:
spin_lock_irqsave(&mac->tx->lock, flags);
start = mac->tx->next_to_clean;
+ ring_limit = mac->tx->next_to_fill;
+
+ /* Compensate for when fill has wrapped but clean has not */
+ if (start > ring_limit)
+ ring_limit += TX_RING_SIZE;
buf_count = 0;
descr_count = 0;
for (i = start;
- descr_count < limit && i < mac->tx->next_to_fill;
+ descr_count < batch_limit && i < ring_limit;
i += buf_count) {
u64 mactx = TX_RING(mac, i);
+ struct sk_buff *skb;
if ((mactx & XCT_MACTX_E) ||
(*mac->tx_status & PAS_STATUS_ERROR))
@@ -651,19 +662,15 @@ restart:
/* Not yet transmitted */
break;
- info = &TX_RING_INFO(mac, i+1);
- skbs[descr_count] = info->skb;
+ skb = TX_RING_INFO(mac, i+1).skb;
+ skbs[descr_count] = skb;
- buf_count = 2 + skb_shinfo(info->skb)->nr_frags;
- for (j = 0; j <= skb_shinfo(info->skb)->nr_frags; j++)
+ buf_count = 2 + skb_shinfo(skb)->nr_frags;
+ for (j = 0; j <= skb_shinfo(skb)->nr_frags; j++)
dmas[descr_count][j] = TX_RING_INFO(mac, i+1+j).dma;
-
- info->dma = 0;
TX_RING(mac, i) = 0;
TX_RING(mac, i+1) = 0;
- TX_RING_INFO(mac, i+1).skb = 0;
- TX_RING_INFO(mac, i+1).dma = 0;
/* Since we always fill with an even number of entries, make
* sure we skip any unused one at the end as well.
@@ -672,7 +679,7 @@ restart:
buf_count++;
descr_count++;
}
- mac->tx->next_to_clean = i;
+ mac->tx->next_to_clean = i & (TX_RING_SIZE-1);
spin_unlock_irqrestore(&mac->tx->lock, flags);
netif_wake_queue(mac->netdev);
@@ -683,7 +690,7 @@ restart:
total_count += descr_count;
/* If the batch was full, try to clean more */
- if (descr_count == limit)
+ if (descr_count == batch_limit)
goto restart;
return total_count;
@@ -1106,19 +1113,14 @@ static int pasemi_mac_start_tx(struct sk
spin_lock_irqsave(&txring->lock, flags);
- if (RING_AVAIL(txring) <= nfrags+3) {
- spin_unlock_irqrestore(&txring->lock, flags);
- pasemi_mac_clean_tx(mac);
- pasemi_mac_restart_tx_intr(mac);
- spin_lock_irqsave(&txring->lock, flags);
-
- if (RING_AVAIL(txring) <= nfrags+3) {
- /* Still no room -- stop the queue and wait for tx
- * intr when there's room.
- */
- netif_stop_queue(dev);
- goto out_err;
- }
+ /* Avoid stepping on the same cache line that the DMA controller
+ * is currently about to send, so leave at least 8 words available.
+ * Total free space needed is mactx + fragments + 8
+ */
+ if (RING_AVAIL(txring) < nfrags + 10) {
+ /* no room -- stop the queue and wait for tx intr */
+ netif_stop_queue(dev);
+ goto out_err;
}
TX_RING(mac, txring->next_to_fill) = mactx;
@@ -1137,8 +1139,8 @@ static int pasemi_mac_start_tx(struct sk
if (nfrags & 1)
nfrags++;
- txring->next_to_fill += nfrags + 1;
-
+ txring->next_to_fill = (txring->next_to_fill + nfrags + 1) &
+ (TX_RING_SIZE-1);
dev->stats.tx_packets++;
dev->stats.tx_bytes += skb->len;
^ permalink raw reply
* [PATCH] [6/11] pasemi_mac: add local skb alignment
From: Olof Johansson @ 2007-10-02 21:26 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
In-Reply-To: <20071002212421.GA2282@lixom.net>
pasemi_mac: add local skb alignment
Add local SKB alignment to pasemi_mac, since ppc64 in general has it at 0
because of design flaws in some of the IBM server bridge chips. However,
for PWRficient doing the unaligned copies is more expensive than doing
unaligned DMA so make sure the data is aligned instead.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: k.org/drivers/net/pasemi_mac.c
===================================================================
--- k.org.orig/drivers/net/pasemi_mac.c
+++ k.org/drivers/net/pasemi_mac.c
@@ -37,6 +37,12 @@
#include "pasemi_mac.h"
+/* We have our own align, since ppc64 in general has it at 0 because
+ * of design flaws in some of the server bridge chips. However, for
+ * PWRficient doing the unaligned copies is more expensive than doing
+ * unaligned DMA, so make sure the data is aligned instead.
+ */
+#define LOCAL_SKB_ALIGN 2
/* TODO list
*
@@ -409,13 +415,16 @@ static void pasemi_mac_replenish_rx_ring
/* skb might still be in there for recycle on short receives */
if (info->skb)
skb = info->skb;
- else
+ else {
skb = dev_alloc_skb(BUF_SIZE);
+ skb_reserve(skb, LOCAL_SKB_ALIGN);
+ }
if (unlikely(!skb))
break;
- dma = pci_map_single(mac->dma_pdev, skb->data, BUF_SIZE,
+ dma = pci_map_single(mac->dma_pdev, skb->data,
+ BUF_SIZE - LOCAL_SKB_ALIGN,
PCI_DMA_FROMDEVICE);
if (unlikely(dma_mapping_error(dma))) {
@@ -553,10 +562,12 @@ static int pasemi_mac_clean_rx(struct pa
len = (macrx & XCT_MACRX_LLEN_M) >> XCT_MACRX_LLEN_S;
if (len < 256) {
- struct sk_buff *new_skb =
- netdev_alloc_skb(mac->netdev, len + NET_IP_ALIGN);
+ struct sk_buff *new_skb;
+
+ new_skb = netdev_alloc_skb(mac->netdev,
+ len + LOCAL_SKB_ALIGN);
if (new_skb) {
- skb_reserve(new_skb, NET_IP_ALIGN);
+ skb_reserve(new_skb, LOCAL_SKB_ALIGN);
memcpy(new_skb->data, skb->data, len);
/* save the skb in buffer_info as good */
skb = new_skb;
^ 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