* away for 1 week
From: David Miller @ 2006-06-30 3:23 UTC (permalink / raw)
To: netdev
Starting friday afternoon I'll be away until next Thursday
evening. I'll read email and merge patches intermittantly,
so please be patient during this time :)
I'll try to merge up as much as I can this evening and do
one final networking push to Linus for 2.6.18
This pretty much means all the major features have to be
in already, as the merge window is likely to close over
the weekend.
I would have really liked to have gotten the ipv6 hw TSO
support bits in. If someone could put that into a mergable
form real fast I might still be able to get that one in.
Otherwise things look pretty good.
^ permalink raw reply
* Re: [PATCH 5/5] tg3: Update version and reldate
From: David Miller @ 2006-06-30 3:16 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1151630976.21798.21.camel@rh4>
From: "Michael Chan" <mchan@broadcom.com>
Date: Thu, 29 Jun 2006 18:29:36 -0700
> Update version to 3.61.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH 4/5] tg3: Add TSO workaround using GSO
From: David Miller @ 2006-06-30 3:16 UTC (permalink / raw)
To: mchan; +Cc: herbert, jk, netdev
In-Reply-To: <1151630967.21798.20.camel@rh4>
From: "Michael Chan" <mchan@broadcom.com>
Date: Thu, 29 Jun 2006 18:29:27 -0700
> Use GSO to workaround a rare TSO bug on some chips. This hardware
> bug may be triggered when the TSO header size is greater than 80
> bytes. When this condition is detected in a TSO packet, the driver
> will use GSO to segment the packet to workaround the hardware bug.
>
> Thanks to Juergen Kreileder <jk@blackdown.de> for reporting the
> problem and collecting traces to help debug the problem.
>
> And thanks to Herbert Xu <herbert@gondor.apana.org.au> for providing
> the GSO mechanism that happens to be the perfect workaround for this
> problem.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Looks really nice. Applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH 3/5] tg3: Turn on hw fix for ASF problems
From: David Miller @ 2006-06-30 3:15 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1151630959.21798.19.camel@rh4>
From: "Michael Chan" <mchan@broadcom.com>
Date: Thu, 29 Jun 2006 18:29:19 -0700
> Clear a bit to enable a hardware fix for some ASF related problem.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH 2/5] tg3: Add rx BD workaround
From: David Miller @ 2006-06-30 3:14 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1151630955.21798.18.camel@rh4>
From: "Michael Chan" <mchan@broadcom.com>
Date: Thu, 29 Jun 2006 18:29:14 -0700
> Add workaround to limit the burst size of rx BDs being DMA'ed to the
> chip. This works around hardware errata on a number of 5750, 5752,
> and 5755 chips.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Ugly bug, but what can we do? :-)
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/5] tg3: Add tg3_netif_stop() in vlan functions
From: David Miller @ 2006-06-30 3:12 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1151630947.21798.17.camel@rh4>
From: "Michael Chan" <mchan@broadcom.com>
Date: Thu, 29 Jun 2006 18:29:06 -0700
> Add tg3_netif_stop() when changing the vlgrp (vlan group) pointer. It
> is necessary to quiesce the device before changing that pointer.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Good catch.
Applied, thanks a lot Michael.
^ permalink raw reply
* Re: [TCP]: Reset gso_segs if packet is dodgy
From: David Miller @ 2006-06-30 3:11 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20060630020044.GA28317@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 30 Jun 2006 12:00:44 +1000
> [TCP]: Reset gso_segs if packet is dodgy
>
> I wasn't paranoid enough in verifying GSO information. A bogus gso_segs
> could upset drivers as much as a bogus header would. Let's reset it in
> the per-protocol gso_segment functions.
>
> I didn't verify gso_size because that can be verified by the source of
> the dodgy packets.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks Herbert.
^ permalink raw reply
* Re: [PATCH] improved statistics for bcm43xx-softmac
From: Larry Finger @ 2006-06-30 3:07 UTC (permalink / raw)
To: Dan Williams; +Cc: John Linville, netdev
In-Reply-To: <1151614610.15090.30.camel@localhost.localdomain>
Dan Williams wrote:
> To me, it looks like you're trying to use dBm rather than RSSI here. In
> that case, you have to set range->max_qual.level to 0, because the upper
> bound of dBm is indeed 0. If you are using negative values _anywhere_
> in your code for quality, you're almost certainly using dBm, not RSSI,
> or something is very wrong.
> Print out the value of 'average' from handle_irq_noise() both when close
> and far away from the AP. It looks to me like the final calculations
> there come out in dBm given the fact that (a) average is negative, and
> (b) that average is in the range of acceptable dBm numbers. So:
>
> 1. set your stats->max_qual.level = 0
> 2. set bcm->stats.link_quality = average
> 3. Do link quality calculation on signal and noise; you can't just be
> linear here though, since a noise floor of -100 with a signal of -90 is
> in reality better than 10% signal; it's actually pretty OK. Each -1 dBm
> step near the noise floor counts for more % than a -1 dBm increase near
> the best signal level. You have to weight the bottom of the scale WRT
> percentage to get values that make sense.
Thanks for explaining how to get dBm into these fields. The comments in include/linux/wireless.h are
confusing.
The quantity listed in stats.rssi has been processed into a dBm value in a routine called
bcm43xx_rssi_postprocess, which I need to mention in the comments. The calculation is more black
magic from the clean-room group's reverse engineering of the Mips driver. I changed the name of the
constant from RSSI_MAX to RX_POWER_MAX, which I estimate to be -10 dBm (see below).
As I move away from the AP, I get the following results:
Dist. "rssi" "average" Link Quality Notes
.3 m -14 -64 96/100 Nearly on top of AP
2 m -27 -62 83/100 Direct line of sight
15 m -55 -65 55/100 Bounce down hallway and/or through wall
20 m -66 -66 44/100 Like 15m point, but through plate glass window
- 35% packet loss with ping
The "Link Quality" above comes from 100 - "rssi" - RX_POWER_MAX, where RX_POWER_MAX is -10.
As "average" does not change, clearly the link quality cannot be derived from that value. It seems
to me that the processed value in the stats.rssi field is not too bad an estimate of the qual.level
(in dBm). The value from "average" is also not a good estimate of the noise, but it is the best I
have at the moment. Clearly, the reported value of qual.qual (Link quality) needs to be adjusted
> ipw2200 for example reports -53 dBm near the AP, with noise floor of -83
> dBm in a fairly spectrum-crowded area. That translates into what
> ipw2200 reports as a 75% signal, which seems a bit off, but gives you an
> idea. You'll never get near 0 dBm, since there's already 10s of dBm
> loss when the signal has to cross any air at all.
I'm now getting a similar result with an 85% signal at 2 m. The main difference is that both signal
and noise seem to be shifted up by about 20 dBm. As these are logarithmic quantities, S/N is
preserved through this offset. My feeling is that these statistics have no absolute meaning, but are
good as relative indicators. When the left-most bar in the Wireless Network Information applet in
the KDE taskbar changes from green to yellow, I know that the signal is degraded.
Thanks for your comments. They made me dig a lot deeper into the numbers.
Larry
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: Shailabh Nagar @ 2006-06-30 3:01 UTC (permalink / raw)
To: hadi
Cc: netdev, linux-kernel, csturtiv, balbir, jlan, Valdis.Kletnieks,
pj, Andrew Morton
In-Reply-To: <1151631048.8922.139.camel@jzny2>
jamal wrote:
>On Thu, 2006-29-06 at 21:11 -0400, Shailabh Nagar wrote:
>
>
>>Andrew Morton wrote:
>>
>>
>>
>>>Shailabh Nagar <nagar@watson.ibm.com> wrote:
>>>
>>>
>[..]
>
>
>>>So if we can detect the silly sustained-high-exit-rate scenario then it
>>>seems to me quite legitimate to do some aggressive data reduction on that.
>>>Like, a single message which says "20,000 sub-millisecond-runtime tasks
>>>exited in the past second" or something.
>>>
>>>
>>>
>>>
>>The "buffering within taskstats" might be a way out then.
>>
>>
>
>Thats what it looks like.
>
>
>
>>As long as the user is willing to pay the price in terms of memory,
>>
>>
>
>You may wanna draw a line to the upper limit - maybe even allocate slab
>space.
>
>
Didn't quite understand...could you please elaborate ?
Today we have a slab cache from which the taskstats structure gets
allocated at the beginning
of the exit() path.
The upper limit to which you refer is the amount of slab memory the user
is willing to be used
to store the bursty traffic ?
>> we can collect the exiting task's taskstats data but not send it
>>immediately (taskstats_cache would grow)
>>unless a high water mark had been crossed. Otherwise a timer event would do the
>>sends of accumalated taskstats (not all at once but
>>iteratively if necessary).
>>
>>
>>
>
>Sounds reasonable. Thats what xfrm events do.
>
>Try to have those
>parameters settable because different machines or users may have
>different view as to what is proper - maybe even as simple as sysctl.
>
>
Sounds good.
>
>
>>At task exit, despite doing a few rounds of sending of pending data, if
>>netlink were still reporting errors
>>then it would be a sign of unsustainable rate and the pending queue
>>could be dropped and a message like you suggest could be sent.
>>
>>
>>
>
>When you send inside the kernel - you will get an error if there's
>problems sending to the socket queue. So you may wanna use that info
>to release the kernel allocated entries or keep them for a little
>longer.
>
>Hopefully that helps.
>
>
Yes it does. Thanks for the tips.
Will code up something and send out so this can become more concrete.
--Shailabh
>cheers,
>jamal
>
>
>
>
^ permalink raw reply
* Re: 2.6.17-mm3 -- BUG: illegal lock usage -- illegal {softirq-on-W} -> {in-softirq-R} usage.
From: Herbert Xu @ 2006-06-30 2:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: arjan, miles.lane, linux-kernel, netdev, davem, yoshfuji
In-Reply-To: <20060629125640.d828a0b3.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> wrote:
>
>> > inet_bind()
>> > ->sk_dst_get
>> > ->read_lock(&sk->sk_dst_lock)
We are still holding the sock lock when doing sk_dst_get.
>> > > 1 lock held by java_vm/4418:
>> > > #0: (af_family_keys + (sk)->sk_family#4){-+..}, at: [<f93c9281>]
>> > > tcp_v6_rcv+0x308/0x7b7 [ipv6]
>> >
>> > softirq
>> > ->ip6_dst_lookup
>> > ->sk_dst_check
>> > ->sk_dst_reset
>> > ->write_lock(&sk->sk_dst_lock);
The sock lock prevents this path from being entered. Instead the
received TCP packet is queued and replayed when the sock lock is
released.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: strict isolation of net interfaces
From: Sam Vilain @ 2006-06-30 2:49 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Cedric Le Goater, hadi, Herbert Poetzl, Alexey Kuznetsov, viro,
devel, dev, Andrew Morton, netdev, linux-kernel, Andrey Savochkin,
Daniel Lezcano, Ben Greear, Dave Hansen, Alexey Kuznetsov,
Eric W. Biederman
In-Reply-To: <20060630023947.GA24726@sergelap.austin.ibm.com>
Serge E. Hallyn wrote:
> The last one in your diagram confuses me - why foo0:1? I would
> have thought it'd be
>
> host | guest 0 | guest 1 | guest2
> ----------------------+-----------+-----------+--------------
> | | | |
> |-> l0 <-------+-> lo0 ... | lo0 | lo0
> | | | |
> |-> eth0 | | |
> | | | |
> |-> veth0 <--------+-> eth0 | |
> | | | |
> |-> veth1 <--------+-----------+-----------+-> eth0
> | | | |
> |-> veth2 <-------+-----------+-> eth0 |
>
> [...]
>
> So conceptually using a full virtual net device per container
> certainly seems cleaner to me, and it seems like it should be
> simpler by way of statistics gathering etc, but are there actually
> any real gains? Or is the support for multiple IPs per device
> actually enough?
>
Why special case loopback?
Why not:
host | guest 0 | guest 1 | guest2
----------------------+-----------+-----------+--------------
| | | |
|-> lo | | |
| | | |
|-> vlo0 <---------+-> lo | |
| | | |
|-> vlo1 <---------+-----------+-----------+-> lo
| | | |
|-> vlo2 <--------+-----------+-> lo |
| | | |
|-> eth0 | | |
| | | |
|-> veth0 <--------+-> eth0 | |
| | | |
|-> veth1 <--------+-----------+-----------+-> eth0
| | | |
|-> veth2 <-------+-----------+-> eth0 |
Sam.
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: Paul Jackson @ 2006-06-30 2:43 UTC (permalink / raw)
To: Andrew Morton
Cc: nagar, hadi, Valdis.Kletnieks, jlan, balbir, csturtiv,
linux-kernel, netdev
In-Reply-To: <20060629193500.d4676f13.akpm@osdl.org>
Andrew wrote:
> Nah. Stick it in the same cacheline as tasklist_lock (I'm amazed that
> we've continued to get away with a global lock for that).
Yes - a bit amazing. But no sense compounding the problem now.
We shouldn't be adding global locks/modifiable data in the
fork/exit code path if we can help it, without at least
providing some simple way to ameliorate the problem when
folks do start hitting it.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
^ permalink raw reply
* Re: strict isolation of net interfaces
From: Serge E. Hallyn @ 2006-06-30 2:39 UTC (permalink / raw)
To: Cedric Le Goater
Cc: Sam Vilain, hadi, Herbert Poetzl, Alexey Kuznetsov, viro, devel,
dev, Andrew Morton, serue, netdev, linux-kernel, Andrey Savochkin,
Daniel Lezcano, Ben Greear, Dave Hansen, Alexey Kuznetsov,
Eric W. Biederman
In-Reply-To: <44A450D1.2030405@fr.ibm.com>
Quoting Cedric Le Goater (clg@fr.ibm.com):
> Sam Vilain wrote:
> > jamal wrote:
> >>> note: personally I'm absolutely not against virtualizing
> >>> the device names so that each guest can have a separate
> >>> name space for devices, but there should be a way to
> >>> 'see' _and_ 'identify' the interfaces from outside
> >>> (i.e. host or spectator context)
> >>>
> >>>
> >> Makes sense for the host side to have naming convention tied
> >> to the guest. Example as a prefix: guest0-eth0. Would it not
> >> be interesting to have the host also manage these interfaces
> >> via standard tools like ip or ifconfig etc? i.e if i admin up
> >> guest0-eth0, then the user in guest0 will see its eth0 going
> >> up.
> >
> > That particular convention only works if you have network namespaces and
> > UTS namespaces tightly bound. We plan to have them separate - so for
> > that to work, each network namespace could have an arbitrary "prefix"
> > that determines what the interface name will look like from the outside
> > when combined. We'd have to be careful about length limits.
> >
> > And guest0-eth0 doesn't necessarily make sense; it's not really an
> > ethernet interface, more like a tun or something.
> >
> > So, an equally good convention might be to use sequential prefixes on
> > the host, like "tun", "dummy", or a new prefix - then a property of that
> > is what the name of the interface is perceived to be to those who are in
> > the corresponding network namespace.
> >
> > Then the pragmatic question becomes how to correlate what you see from
> > `ip addr list' to guests.
>
>
> we could work on virtualizing the net interfaces in the host, map them to
> eth0 or something in the guest and let the guest handle upper network layers ?
>
> lo0 would just be exposed relying on skbuff tagging to discriminate traffic
> between guests.
This seems to me the preferable way. We create a full virtual net
device for each new container, and fully virtualize the device
namespace.
> host | guest 0 | guest 1 | guest2
> ----------------------+-----------+-----------+--------------
> | | | |
> |-> l0 <-------+-> lo0 ... | lo0 | lo0
> | | | |
> |-> bar0 <--------+-> eth0 | |
> | | | |
> |-> foo0 <--------+-----------+-----------+-> eth0
> | | | |
> `-> foo0:1 <-------+-----------+-> eth0 |
> | | |
>
>
> is that clear ? stupid ? reinventing the wheel ?
The last one in your diagram confuses me - why foo0:1? I would
have thought it'd be
host | guest 0 | guest 1 | guest2
----------------------+-----------+-----------+--------------
| | | |
|-> l0 <-------+-> lo0 ... | lo0 | lo0
| | | |
|-> eth0 | | |
| | | |
|-> veth0 <--------+-> eth0 | |
| | | |
|-> veth1 <--------+-----------+-----------+-> eth0
| | | |
|-> veth2 <-------+-----------+-> eth0 |
I think we should avoid using device aliases, as trying to do
something like giving eth0:1 to guest1 and eth0:2 to guest2
while hiding eth0:1 from guest2 requires some uglier code (as
I recall) than working with full devices. In other words,
if a namespace can see eth0, and eth0:2 exists, it should always
see eth0:2.
So conceptually using a full virtual net device per container
certainly seems cleaner to me, and it seems like it should be
simpler by way of statistics gathering etc, but are there actually
any real gains? Or is the support for multiple IPs per device
actually enough?
Herbert, is this basically how ngnet is supposed to work?
-serge
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: Andrew Morton @ 2006-06-30 2:35 UTC (permalink / raw)
To: Paul Jackson
Cc: nagar, hadi, Valdis.Kletnieks, jlan, balbir, csturtiv,
linux-kernel, netdev
In-Reply-To: <20060629192526.360aa579.pj@sgi.com>
On Thu, 29 Jun 2006 19:25:26 -0700
Paul Jackson <pj@sgi.com> wrote:
> Andrew wrote:
> > Like, a single message which says "20,000 sub-millisecond-runtime tasks
> > exited in the past second" or something.
>
> System wide accumulation of such data in the exit() code path still
> risks being a bottleneck, just a bit later on.
Nah. Stick it in the same cacheline as tasklist_lock (I'm amazed that
we've continued to get away with a global lock for that).
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: Paul Jackson @ 2006-06-30 2:25 UTC (permalink / raw)
To: Andrew Morton
Cc: nagar, hadi, Valdis.Kletnieks, jlan, balbir, csturtiv,
linux-kernel, netdev
In-Reply-To: <20060629180502.3987a98e.akpm@osdl.org>
Andrew wrote:
> Like, a single message which says "20,000 sub-millisecond-runtime tasks
> exited in the past second" or something.
System wide accumulation of such data in the exit() code path still
risks being a bottleneck, just a bit later on.
I'm more inclined now to look for ways to disable collection on some
CPUs, and/or to allow for multiple streams in the future, as need be,
along the lines of Shailabh's multiple TASKSTATS_LISTEN_GROUPs.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
^ permalink raw reply
* Re: [PATCH 2.6.17] support for TSO over IPv6
From: Herbert Xu @ 2006-06-30 2:11 UTC (permalink / raw)
To: Michael Chan
Cc: Ananda Raju, netdev, jgarzik, shemminger, Leonid.Grossman,
Ravinandan.Arakali, sivakumar.subramani, Sriram.Rapuru
In-Reply-To: <1151633211.21798.25.camel@rh4>
On Thu, Jun 29, 2006 at 07:06:51PM -0700, Michael Chan wrote:
>
> Don't we have a bigger problem if it doesn't support ECN with ipv6 TSO?
> We either have to disable ECN when TSO is enabled like we used to for
> ipv4, or provide the gso tcp segmentation for ipv6. Right?
Good point. In that case we should also add GSO for IPv6. It shouldn't
be too bad because all we need to do is verify the integrity of the
extension headers in terms of their length, not their content.
I wonder if this chip handles all the extension headers or not.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2.6.17] support for TSO over IPv6
From: Michael Chan @ 2006-06-30 2:06 UTC (permalink / raw)
To: Herbert Xu
Cc: Ananda Raju, netdev, jgarzik, shemminger, Leonid.Grossman,
Ravinandan.Arakali, sivakumar.subramani, Sriram.Rapuru
In-Reply-To: <20060630003906.GA27200@gondor.apana.org.au>
On Fri, 2006-06-30 at 10:39 +1000, Herbert Xu wrote:
> BTW, does your card handle ECN correctly? If not then we should change
> the new ECN bit to apply to both TCPv4 and TCPv6 since
>
> 1) We now have a piece of hardware that handles TSO6 and it doesn't do ECN.
> 2) It's quite likely that if the NIC can handle ECN in TCPv4 then it can do
> it in TCPv6.
Don't we have a bigger problem if it doesn't support ECN with ipv6 TSO?
We either have to disable ECN when TSO is enabled like we used to for
ipv4, or provide the gso tcp segmentation for ipv6. Right?
^ permalink raw reply
* [TCP]: Reset gso_segs if packet is dodgy
From: Herbert Xu @ 2006-06-30 2:00 UTC (permalink / raw)
To: David S. Miller, netdev
Hi Dave:
I forgot to verify gso_segs on packets from untrusted sources. In fact
looking around it seems that gso_segs is used by exactly one driver outside
of the TCP stack. In fact it also happens to be a virtual driver: s390/qeth.
Since the only other GSO user we have at the moment -- UFO, doesn't even set
gso_segs, I'd like to move it to skb->cb and get rid of this. However, for
now let's simply reset it in tcp_tso_segment.
[TCP]: Reset gso_segs if packet is dodgy
I wasn't paranoid enough in verifying GSO information. A bogus gso_segs
could upset drivers as much as a bogus header would. Let's reset it in
the per-protocol gso_segment functions.
I didn't verify gso_size because that can be verified by the source of
the dodgy packets.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 0336422..0bb0ac9 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2166,13 +2166,19 @@ struct sk_buff *tcp_tso_segment(struct s
if (!pskb_may_pull(skb, thlen))
goto out;
- segs = NULL;
- if (skb_gso_ok(skb, features | NETIF_F_GSO_ROBUST))
- goto out;
-
oldlen = (u16)~skb->len;
__skb_pull(skb, thlen);
+ if (skb_gso_ok(skb, features | NETIF_F_GSO_ROBUST)) {
+ /* Packet is from an untrusted source, reset gso_segs. */
+ int mss = skb_shinfo(skb)->gso_size;
+
+ skb_shinfo(skb)->gso_segs = (skb->len + mss - 1) / mss;
+
+ segs = NULL;
+ goto out;
+ }
+
segs = skb_segment(skb, features);
if (IS_ERR(segs))
goto out;
^ permalink raw reply related
* Re: [patch 2/6] [Network namespace] Network device sharing by view
From: Sam Vilain @ 2006-06-30 1:41 UTC (permalink / raw)
To: Eric W. Biederman
Cc: hadi, Herbert Poetzl, Alexey Kuznetsov, viro, devel, dev,
Andrew Morton, clg, serue, netdev, linux-kernel, Andrey Savochkin,
Daniel Lezcano, Ben Greear, Dave Hansen, Alexey Kuznetsov
In-Reply-To: <m1veqlgx91.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
>> Makes sense for the host side to have naming convention tied
>> to the guest. Example as a prefix: guest0-eth0. Would it not
>> be interesting to have the host also manage these interfaces
>> via standard tools like ip or ifconfig etc? i.e if i admin up
>> guest0-eth0, then the user in guest0 will see its eth0 going
>> up.
>>
> Please no.
> [...]
> Now I am open to radically different designs if they allow the
> implementation cost to be lower and they have clean semantics,
> and don't wind up being an ugly unmaintainable wart on the linux
> networking stack. The only route I could imagine such a thing coming
> from is something like tagging flows, in some netfiler like way.
> Which might allow ifconfig guest-eth0 from the host without problems.
> But I have not seen such a design.
>
Right. New tools to support new features would probably be tidier, anyway.
Sam.
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: jamal @ 2006-06-30 1:30 UTC (permalink / raw)
To: Shailabh Nagar
Cc: netdev, linux-kernel, csturtiv, balbir, jlan, Valdis.Kletnieks,
pj, Andrew Morton
In-Reply-To: <44A47A3E.5070809@watson.ibm.com>
On Thu, 2006-29-06 at 21:11 -0400, Shailabh Nagar wrote:
> Andrew Morton wrote:
>
> >Shailabh Nagar <nagar@watson.ibm.com> wrote:
[..]
> >So if we can detect the silly sustained-high-exit-rate scenario then it
> >seems to me quite legitimate to do some aggressive data reduction on that.
> >Like, a single message which says "20,000 sub-millisecond-runtime tasks
> >exited in the past second" or something.
> >
> >
> The "buffering within taskstats" might be a way out then.
Thats what it looks like.
> As long as the user is willing to pay the price in terms of memory,
You may wanna draw a line to the upper limit - maybe even allocate slab
space.
> we can collect the exiting task's taskstats data but not send it
> immediately (taskstats_cache would grow)
> unless a high water mark had been crossed. Otherwise a timer event would do the
> sends of accumalated taskstats (not all at once but
> iteratively if necessary).
>
Sounds reasonable. Thats what xfrm events do. Try to have those
parameters settable because different machines or users may have
different view as to what is proper - maybe even as simple as sysctl.
> At task exit, despite doing a few rounds of sending of pending data, if
> netlink were still reporting errors
> then it would be a sign of unsustainable rate and the pending queue
> could be dropped and a message like you suggest could be sent.
>
When you send inside the kernel - you will get an error if there's
problems sending to the socket queue. So you may wanna use that info
to release the kernel allocated entries or keep them for a little
longer.
Hopefully that helps.
cheers,
jamal
^ permalink raw reply
* [PATCH 5/5] tg3: Update version and reldate
From: Michael Chan @ 2006-06-30 1:29 UTC (permalink / raw)
To: davem; +Cc: netdev
Update version to 3.61.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 63d4b2c..47c96fc 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -69,8 +69,8 @@
#define DRV_MODULE_NAME "tg3"
#define PFX DRV_MODULE_NAME ": "
-#define DRV_MODULE_VERSION "3.60"
-#define DRV_MODULE_RELDATE "June 17, 2006"
+#define DRV_MODULE_VERSION "3.61"
+#define DRV_MODULE_RELDATE "June 29, 2006"
#define TG3_DEF_MAC_MODE 0
#define TG3_DEF_RX_MODE 0
^ permalink raw reply related
* [PATCH 4/5] tg3: Add TSO workaround using GSO
From: Michael Chan @ 2006-06-30 1:29 UTC (permalink / raw)
To: davem, herbert; +Cc: jk, netdev
Use GSO to workaround a rare TSO bug on some chips. This hardware
bug may be triggered when the TSO header size is greater than 80
bytes. When this condition is detected in a TSO packet, the driver
will use GSO to segment the packet to workaround the hardware bug.
Thanks to Juergen Kreileder <jk@blackdown.de> for reporting the
problem and collecting traces to help debug the problem.
And thanks to Herbert Xu <herbert@gondor.apana.org.au> for providing
the GSO mechanism that happens to be the perfect workaround for this
problem.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 2c36e70..63d4b2c 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -3880,6 +3880,40 @@ out_unlock:
return NETDEV_TX_OK;
}
+#if TG3_TSO_SUPPORT != 0
+static int tg3_start_xmit_dma_bug(struct sk_buff *, struct net_device *);
+
+/* Use GSO to workaround a rare TSO bug that may be triggered when the
+ * TSO header is greater than 80 bytes.
+ */
+static int tg3_tso_bug(struct tg3 *tp, struct sk_buff *skb)
+{
+ struct sk_buff *segs, *nskb;
+
+ /* Estimate the number of fragments in the worst case */
+ if (unlikely(TX_BUFFS_AVAIL(tp) <= (skb_shinfo(skb)->gso_segs * 3))) {
+ netif_stop_queue(tp->dev);
+ return NETDEV_TX_BUSY;
+ }
+
+ segs = skb_gso_segment(skb, tp->dev->features & ~NETIF_F_TSO);
+ if (unlikely(IS_ERR(segs)))
+ goto tg3_tso_bug_end;
+
+ do {
+ nskb = segs;
+ segs = segs->next;
+ nskb->next = NULL;
+ tg3_start_xmit_dma_bug(nskb, tp->dev);
+ } while (segs);
+
+tg3_tso_bug_end:
+ dev_kfree_skb(skb);
+
+ return NETDEV_TX_OK;
+}
+#endif
+
/* hard_start_xmit for devices that have the 4G bug and/or 40-bit bug and
* support TG3_FLG2_HW_TSO_1 or firmware TSO only.
*/
@@ -3916,7 +3950,7 @@ static int tg3_start_xmit_dma_bug(struct
mss = 0;
if (skb->len > (tp->dev->mtu + ETH_HLEN) &&
(mss = skb_shinfo(skb)->gso_size) != 0) {
- int tcp_opt_len, ip_tcp_len;
+ int tcp_opt_len, ip_tcp_len, hdr_len;
if (skb_header_cloned(skb) &&
pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) {
@@ -3927,11 +3961,16 @@ static int tg3_start_xmit_dma_bug(struct
tcp_opt_len = ((skb->h.th->doff - 5) * 4);
ip_tcp_len = (skb->nh.iph->ihl * 4) + sizeof(struct tcphdr);
+ hdr_len = ip_tcp_len + tcp_opt_len;
+ if (unlikely((ETH_HLEN + hdr_len) > 80) &&
+ (tp->tg3_flags2 & TG3_FLG2_HW_TSO_1_BUG))
+ return (tg3_tso_bug(tp, skb));
+
base_flags |= (TXD_FLAG_CPU_PRE_DMA |
TXD_FLAG_CPU_POST_DMA);
skb->nh.iph->check = 0;
- skb->nh.iph->tot_len = htons(mss + ip_tcp_len + tcp_opt_len);
+ skb->nh.iph->tot_len = htons(mss + hdr_len);
if (tp->tg3_flags2 & TG3_FLG2_HW_TSO) {
skb->h.th->check = 0;
base_flags &= ~TXD_FLAG_TCPUDP_CSUM;
@@ -10192,8 +10231,14 @@ static int __devinit tg3_get_invariants(
GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5787) {
tp->tg3_flags2 |= TG3_FLG2_HW_TSO_2;
tp->tg3_flags2 |= TG3_FLG2_1SHOT_MSI;
- } else
- tp->tg3_flags2 |= TG3_FLG2_HW_TSO_1;
+ } else {
+ tp->tg3_flags2 |= TG3_FLG2_HW_TSO_1 |
+ TG3_FLG2_HW_TSO_1_BUG;
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) ==
+ ASIC_REV_5750 &&
+ tp->pci_chip_rev_id >= CHIPREV_ID_5750_C2)
+ tp->tg3_flags2 &= ~TG3_FLG2_HW_TSO_1_BUG;
+ }
}
if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5705 &&
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index 97a8604..ba2c987 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -125,6 +125,7 @@
#define CHIPREV_ID_5750_A0 0x4000
#define CHIPREV_ID_5750_A1 0x4001
#define CHIPREV_ID_5750_A3 0x4003
+#define CHIPREV_ID_5750_C2 0x4202
#define CHIPREV_ID_5752_A0_HW 0x5000
#define CHIPREV_ID_5752_A0 0x6000
#define CHIPREV_ID_5752_A1 0x6001
@@ -2193,7 +2194,7 @@ struct tg3 {
#define TG3_FLAG_INIT_COMPLETE 0x80000000
u32 tg3_flags2;
#define TG3_FLG2_RESTART_TIMER 0x00000001
-/* 0x00000002 available */
+#define TG3_FLG2_HW_TSO_1_BUG 0x00000002
#define TG3_FLG2_NO_ETH_WIRE_SPEED 0x00000004
#define TG3_FLG2_IS_5788 0x00000008
#define TG3_FLG2_MAX_RXPEND_64 0x00000010
^ permalink raw reply related
* [PATCH 2/5] tg3: Add rx BD workaround
From: Michael Chan @ 2006-06-30 1:29 UTC (permalink / raw)
To: davem; +Cc: netdev
Add workaround to limit the burst size of rx BDs being DMA'ed to the
chip. This works around hardware errata on a number of 5750, 5752,
and 5755 chips.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 2447fa3..c32655c 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -3195,7 +3195,7 @@ static int tg3_vlan_rx(struct tg3 *tp, s
*/
static int tg3_rx(struct tg3 *tp, int budget)
{
- u32 work_mask;
+ u32 work_mask, rx_std_posted = 0;
u32 sw_idx = tp->rx_rcb_ptr;
u16 hw_idx;
int received;
@@ -3222,6 +3222,7 @@ static int tg3_rx(struct tg3 *tp, int bu
mapping);
skb = tp->rx_std_buffers[desc_idx].skb;
post_ptr = &tp->rx_std_ptr;
+ rx_std_posted++;
} else if (opaque_key == RXD_OPAQUE_RING_JUMBO) {
dma_addr = pci_unmap_addr(&tp->rx_jumbo_buffers[desc_idx],
mapping);
@@ -3309,6 +3310,15 @@ static int tg3_rx(struct tg3 *tp, int bu
next_pkt:
(*post_ptr)++;
+
+ if (unlikely(rx_std_posted >= tp->rx_std_max_post)) {
+ u32 idx = *post_ptr % TG3_RX_RING_SIZE;
+
+ tw32_rx_mbox(MAILBOX_RCV_STD_PROD_IDX +
+ TG3_64BIT_REG_LOW, idx);
+ work_mask &= ~RXD_OPAQUE_RING_STD;
+ rx_std_posted = 0;
+ }
next_pkt_nopost:
sw_idx++;
sw_idx %= TG3_RX_RCB_RING_SIZE(tp);
@@ -5981,7 +5991,13 @@ static int tg3_reset_hw(struct tg3 *tp,
}
/* Setup replenish threshold. */
- tw32(RCVBDI_STD_THRESH, tp->rx_pending / 8);
+ val = tp->rx_pending / 8;
+ if (val == 0)
+ val = 1;
+ else if (val > tp->rx_std_max_post)
+ val = tp->rx_std_max_post;
+
+ tw32(RCVBDI_STD_THRESH, val);
/* Initialize TG3_BDINFO's at:
* RCVDBDI_STD_BD: standard eth size rx ring
@@ -10545,6 +10561,16 @@ static int __devinit tg3_get_invariants(
(tp->tg3_flags & TG3_FLAG_PCIX_MODE) != 0)
tp->rx_offset = 0;
+ tp->rx_std_max_post = TG3_RX_RING_SIZE;
+
+ /* Increment the rx prod index on the rx std ring by at most
+ * 8 for these chips to workaround hw errata.
+ */
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5750 ||
+ GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5752 ||
+ GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5755)
+ tp->rx_std_max_post = 8;
+
/* By default, disable wake-on-lan. User can change this
* using ETHTOOL_SWOL.
*/
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index 8209da5..e9177f8 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -2137,6 +2137,7 @@ struct tg3 {
struct tg3_rx_buffer_desc *rx_std;
struct ring_info *rx_std_buffers;
dma_addr_t rx_std_mapping;
+ u32 rx_std_max_post;
struct tg3_rx_buffer_desc *rx_jumbo;
struct ring_info *rx_jumbo_buffers;
^ permalink raw reply related
* [PATCH 3/5] tg3: Turn on hw fix for ASF problems
From: Michael Chan @ 2006-06-30 1:29 UTC (permalink / raw)
To: davem; +Cc: netdev
Clear a bit to enable a hardware fix for some ASF related problem.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index c32655c..2c36e70 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -6157,8 +6157,12 @@ static int tg3_reset_hw(struct tg3 *tp,
#endif
/* Receive/send statistics. */
- if ((rdmac_mode & RDMAC_MODE_FIFO_SIZE_128) &&
- (tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE)) {
+ if (tp->tg3_flags2 & TG3_FLG2_5750_PLUS) {
+ val = tr32(RCVLPC_STATS_ENABLE);
+ val &= ~RCVLPC_STATSENAB_DACK_FIX;
+ tw32(RCVLPC_STATS_ENABLE, val);
+ } else if ((rdmac_mode & RDMAC_MODE_FIFO_SIZE_128) &&
+ (tp->tg3_flags2 & TG3_FLG2_TSO_CAPABLE)) {
val = tr32(RCVLPC_STATS_ENABLE);
val &= ~RCVLPC_STATSENAB_LNGBRST_RFIX;
tw32(RCVLPC_STATS_ENABLE, val);
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index e9177f8..97a8604 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -760,6 +760,7 @@
#define RCVLPC_STATSCTRL_ENABLE 0x00000001
#define RCVLPC_STATSCTRL_FASTUPD 0x00000002
#define RCVLPC_STATS_ENABLE 0x00002018
+#define RCVLPC_STATSENAB_DACK_FIX 0x00040000
#define RCVLPC_STATSENAB_LNGBRST_RFIX 0x00400000
#define RCVLPC_STATS_INCMASK 0x0000201c
/* 0x2020 --> 0x2100 unused */
^ permalink raw reply related
* [PATCH 1/5] tg3: Add tg3_netif_stop() in vlan functions
From: Michael Chan @ 2006-06-30 1:29 UTC (permalink / raw)
To: davem; +Cc: netdev
Add tg3_netif_stop() when changing the vlgrp (vlan group) pointer. It
is necessary to quiesce the device before changing that pointer.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 35f9316..2447fa3 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -8738,6 +8738,9 @@ static void tg3_vlan_rx_register(struct
{
struct tg3 *tp = netdev_priv(dev);
+ if (netif_running(dev))
+ tg3_netif_stop(tp);
+
tg3_full_lock(tp, 0);
tp->vlgrp = grp;
@@ -8746,16 +8749,25 @@ static void tg3_vlan_rx_register(struct
__tg3_set_rx_mode(dev);
tg3_full_unlock(tp);
+
+ if (netif_running(dev))
+ tg3_netif_start(tp);
}
static void tg3_vlan_rx_kill_vid(struct net_device *dev, unsigned short vid)
{
struct tg3 *tp = netdev_priv(dev);
+ if (netif_running(dev))
+ tg3_netif_stop(tp);
+
tg3_full_lock(tp, 0);
if (tp->vlgrp)
tp->vlgrp->vlan_devices[vid] = NULL;
tg3_full_unlock(tp);
+
+ if (netif_running(dev))
+ tg3_netif_start(tp);
}
#endif
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox