Re: fixing sk_stream_rfree()
On Sun, Apr 16, 2006 at 10:32:03PM -0700, David S. Miller wrote:
>
> Let me save you some time, later in the thread you'll find
> out that this whole thing is a dead end.
Thanks. I even read the message but managed to miss your conclusion :)
> So it nearly has to be a send side issue that can only trigger with
> TSO enabled, and my next planned chore is to audit the TSO splitting
> during ACK processing. We may be doing something stupid there.
BTW, do we have a dmesg log from the machine that did this with tg3?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: fixing sk_stream_rfree()
From: Herbert Xu <[EMAIL PROTECTED]> Date: Sun, 16 Apr 2006 21:18:31 +1000 > Great eyes! Yes that bug seems to have been around forever. I'll > look over the patch tomorrow as right now I'm still on west-coast > time :) Let me save you some time, later in the thread you'll find out that this whole thing is a dead end. The reason is that all SKBs are unshared when we receive them into the TCP stack for sk->sk_receive_queue. (this is done by ip_rcv()). This means every __kfree_skb() call would happen in the context of the TCP stack with the socket locked, so no concurrency issues wrt. sk_forward_alloc as I originally thought. In fact, this is what makes using __kfree_skb() explicitly legal in the first place. If skb->users could be non-zero, from tcpdump etc., then we'd be required to call kfree_skb() in the TCP code that frees up used packets on the receive queue. But all is not lost, this is an important datapoint. We've audited the receive side accesses to sk_forward_alloc and it all looks good. And again, as you mention, we go back again to TSO being the deciding factor in triggering this or not. So it nearly has to be a send side issue that can only trigger with TSO enabled, and my next planned chore is to audit the TSO splitting during ACK processing. We may be doing something stupid there. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: skb diet
From: Andi Kleen <[EMAIL PROTECTED]> Date: Sun, 16 Apr 2006 17:16:31 +0200 > On Sunday 16 April 2006 14:56, Hisham Kotry wrote: > > > Linux 2.0 did something like this, but that was removed for good > > > reasons. Now TCP always clones skbs before sending it out. > > > > Do you remember what those reasons were? I couldn't find a related > > discussion in the archives. I think the BSD mbuf tags approach is > > sound enough to justify the move. > > From your description so far it seems to only have disadvantages. I totally agree, tags are very stupid. I only brought them up long as food-for-thought, not as a very serious candidate for implementation. Indirection is a performance killer, and we've seen this time and time again in the past. Tags add more indirection for questionable gains. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ipw2100: wraps the debug module param within #ifdefs
On Fri, 2006-04-14 at 09:33 -0700, Stephen Hemminger wrote: > I meant get rid of CONFIG_IPW2200_DEBUG completely. Having the debug code > isn't > bad, and there is no reason not to have it always there. There are lots of IPW_DEBUG_XXX in the driver, even in TX and RX paths. It cause extra cycles for those who really don't need it. Thanks, -yi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: how to do probabilistic packet loss in kernel?
On 4/17/06, George P Nychis <[EMAIL PROTECTED]> wrote: > Hi, > > I am using iproute2 to setup fowarding, adding routes like "ip route add > 192.168.1.3 via 192.168.1.2" > > I was wondering where in the kernel I can insert probabilistic packet loss > only for forwarded packets? So that for instance I can drop 5% of all > forwarded packets? > Have a look at: http://linux-net.osdl.org/index.php/Netem -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix crash on big-endian systems during scan
On Fri, Apr 14, 2006 at 05:59:11PM -0400, Pavel Roskin wrote: > The original code was doing arithmetics on a little-endian value. John, please apply this to wireless-2.6 tree. This code is triggered at least for the case where WPA is not used. I had noticed it before, but I think I've only tested WPA/WPA2 on big endian systems.. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] softmac: suggest TX rate
Ulrich Kunitz wrote: I just wanted to say, I agree with the approach, but wonder how transmission timeouts come into play here, which should lead to a decrease of the tranmission rate. That's a separate issue, to do with rate management, which I'm not tackling yet. Note that the functions in my patch can easily be extended to bring rate management into the equation. Daniel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] softmac: suggest TX rate
On Mon, 17 Apr 2006, Ulrich Kunitz wrote: Oops! Sorry, but sometime ^X and ^C are to near to each other. I just wanted to say, I agree with the approach, but wonder how transmission timeouts come into play here, which should lead to a decrease of the tranmission rate. Daniel the patches on branch softmac-suggest-txrate look good! Regards, Uli -- Ulrich Kunitz - [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] softmac: suggest TX rate
On Mon, 17 Apr 2006, Daniel Drake wrote: > While developing the ZD1211 driver we realised how much we'd like to be > advised from the upper layers which rate to transmit a packet at. > > An example: We have a frame to transmit. What rate should we transmit it at? > While taking any user-specified rate into account too, we want to transmit it > at a rate supported by the access point, but that information is not available > to us (softmac handled all scanning and association, so we don't know anything > about the AP capabilities). > > Here is a patch I cooked up, which implements some basic logic for suggesting > TX rates based on the packet type, whether it is multicast/unicast, whether we > are associated, and the current user-specified default_rate. > > I'm still uncertain where this functionality should fit into the stack. > > Rather than having to explicitly call ieee80211softmac_suggest_tx_rate() from > the driver's hard_start_xmit function, it would be nicer if the suggested rate > was passed as a parameter. But not all drivers would need it, so maybe the > extra calculations should be controlled by a new flag. > > Passing an extra parameter to hard_start_xmit would involve modifying > ieee80211, and ieee80211 doesn't seem to have any concept of whether it is > associated or not (plus softmac only does that loosely). So that might lead us > on to do something silly like wrapping hard_start_xmit inside softmac, etc > etc... > > Note that even in it's current form, this patch eliminates an annoying (and > inaccurate) chunk of code from our driver. > > Ideas/comments? > -- Ulrich Kunitz - [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][RFC] softmac: suggest TX rate
While developing the ZD1211 driver we realised how much we'd like to be
advised from the upper layers which rate to transmit a packet at.
An example: We have a frame to transmit. What rate should we transmit it
at? While taking any user-specified rate into account too, we want to
transmit it at a rate supported by the access point, but that
information is not available to us (softmac handled all scanning and
association, so we don't know anything about the AP capabilities).
Here is a patch I cooked up, which implements some basic logic for
suggesting TX rates based on the packet type, whether it is
multicast/unicast, whether we are associated, and the current
user-specified default_rate.
I'm still uncertain where this functionality should fit into the stack.
Rather than having to explicitly call ieee80211softmac_suggest_tx_rate()
from the driver's hard_start_xmit function, it would be nicer if the
suggested rate was passed as a parameter. But not all drivers would need
it, so maybe the extra calculations should be controlled by a new flag.
Passing an extra parameter to hard_start_xmit would involve modifying
ieee80211, and ieee80211 doesn't seem to have any concept of whether it
is associated or not (plus softmac only does that loosely). So that
might lead us on to do something silly like wrapping hard_start_xmit
inside softmac, etc etc...
Note that even in it's current form, this patch eliminates an annoying
(and inaccurate) chunk of code from our driver.
Ideas/comments?
--- linux/net/ieee80211/softmac/ieee80211softmac_module.c.orig 2006-04-17
01:04:42.0 +0100
+++ linux/net/ieee80211/softmac/ieee80211softmac_module.c 2006-04-17
00:44:36.0 +0100
@@ -26,6 +26,7 @@
#include "ieee80211softmac_priv.h"
#include
+#include
struct net_device *alloc_ieee80211softmac(int sizeof_priv)
{
@@ -315,6 +316,48 @@ static int rate_cmp(const void *a_, cons
return ((*a & ~IEEE80211_BASIC_RATE_MASK) - (*b &
~IEEE80211_BASIC_RATE_MASK));
}
+static u8 suggest_rate_from_associnfo(struct ieee80211softmac_device *mac)
+{
+ struct ieee80211softmac_ratesinfo *net_rates =
&mac->associnfo.supported_rates;
+ u8 net_max;
+
+ if (unlikely(net_rates->count == 0)) {
+ dprintkl(KERN_ERROR PFX "suggest_rate: Network has no
rates?\n");
+ return IEEE80211_CCK_RATE_1MB;
+ }
+
+ /* FIXME: we need to check that the rate is supported in mac->ratesinfo
*/
+ net_max = net_rates->rates[net_rates->count - 1];
+ return min(mac->txrates.default_rate, net_max);
+}
+
+u8 ieee80211softmac_suggest_tx_rate(struct ieee80211softmac_device *mac,
+ struct ieee80211_hdr_1addr *hdr)
+{
+ switch (WLAN_FC_GET_TYPE(le16_to_cpu(hdr->frame_ctl))) {
+ case IEEE80211_FTYPE_MGMT:
+ /*
+* If we aren't associated, or we are multicasting, then
+* stick to 1MB for safety.
+*/
+ if (!mac->associated || is_multicast_ether_addr(hdr->addr1))
+ return IEEE80211_CCK_RATE_1MB;
+
+ /* Otherwise, we can send at the speed of the AP. */
+ return suggest_rate_from_associnfo(mac);
+ case IEEE80211_FTYPE_DATA:
+ if (unlikely(!mac->associated)) {
+ dprintkl(KERN_ERROR PFX "suggest_tx_rate: Not
associated\n");
+ return IEEE80211_CCK_RATE_1MB;
+ }
+ return suggest_rate_from_associnfo(mac);
+ default:
+ dprintkl(KERN_ERROR PFX "suggest_tx_rate: Unhandled ftype
%x\n", ftype);
+ return IEEE80211_CCK_RATE_1MB;
+ }
+}
+EXPORT_SYMBOL_GPL(ieee80211softmac_suggest_tx_rate);
+
/* Allocate a softmac network struct and fill it from a network */
struct ieee80211softmac_network *
ieee80211softmac_create_network(struct ieee80211softmac_device *mac,
--- linux/net/ieee80211/softmac/ieee80211softmac_assoc.c.orig 2006-04-16
23:55:23.0 +0100
+++ linux/net/ieee80211/softmac/ieee80211softmac_assoc.c2006-04-16
23:55:39.0 +0100
@@ -283,6 +283,7 @@ ieee80211softmac_associated(struct ieee8
struct ieee80211softmac_network *net)
{
mac->associnfo.associating = 0;
+ mac->associnfo.supported_rates = net->supported_rates;
mac->associated = 1;
if (mac->set_bssid_filter)
mac->set_bssid_filter(mac->dev, net->bssid);
--- linux/include/net/ieee80211softmac.h.orig 2006-04-16 23:37:32.0
+0100
+++ linux/include/net/ieee80211softmac.h2006-04-17 00:44:47.0
+0100
@@ -86,6 +86,9 @@ struct ieee80211softmac_assoc_info {
/* BSSID we're trying to associate to */
char bssid[ETH_ALEN];
+
+ /* Rates supported by the network */
+ struct ieee80211softmac_ratesinfo supported_rates;
/* some flags.
* static_essid is valid if the essid is constant,
@@ -246,
Re: r8169 locks up in 2.6.16.5
> How much long was the card under load ? A few seconds ? > The same 1500 bytes mtu is used everywhere and the issue can not be > reproduced with a simple ping -f -q -l 64 -s what_you_want aimed at > the 8169, right ? Correct, > > What next? > > ethtool -d/-S before and after failure, .config and /proc/interrupts. Ok, here it all is, the attached archive has: - .before is right after the interface came up - .mid is after flooding it with ping -f commands from 2 machines at once - .bad is after doing the cpio over nc that killed it after 170MB - .back is after ifconfig down / ifconfig up that restored it Note, the kernel config has SMP etc turned back on, as it doesn't seem to affect things, and the eepro100 back on eth0, I'm testing this against eth1 so that the machine can be normally useful as well... r8169-bad/ifconfig.before r8169-bad/dmesg.before r8169-bad/arp-n.before r8169-bad/ethtool-d.before r8169-bad/ethtool-S.before r8169-bad/config.gz r8169-bad/proc-interrupts.before r8169-bad/ping-during r8169-bad/dmesg.mid r8169-bad/arp-n.mid r8169-bad/ifconfig.mid r8169-bad/ethtool-d.mid r8169-bad/ethtool-S.mid r8169-bad/proc-interrupts.mid r8169-bad/ifconfig.bad r8169-bad/dmesg.bad r8169-bad/ethtool-d.bad r8169-bad/ethtool-S.bad r8169-bad/proc-interrupts.bad r8169-bad/ifconfig.back r8169-bad/dmesg.back r8169-bad/ethtool-d.back r8169-bad/ethtool-S.back r8169-bad/proc-interrupts.back -Thanks, -Tom r8169-bad.tar.bz2 Description: Binary data
how to do probabilistic packet loss in kernel?
Hi, I am using iproute2 to setup fowarding, adding routes like "ip route add 192.168.1.3 via 192.168.1.2" I was wondering where in the kernel I can insert probabilistic packet loss only for forwarded packets? So that for instance I can drop 5% of all forwarded packets? I don't need help with the actual code, just need help finding where to insert this code :) Thanks! George - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 locks up in 2.6.16.5
Thomas A. Oehser <[EMAIL PROTECTED]> : [...] > > I'll welcome a complete dmesg after you have recovered through > > ifconfig down/up though. > > _Nothing_ on dmesg. Huh... Nothing appears when you issue 'dmesg' ? [...] > eth1 Link encap:Ethernet HWaddr 00:E0:4C:13:A9:56 > inet addr:192.168.99.99 Bcast:192.168.99.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:528416 errors:252 dropped:620 overruns:0 frame:966 > TX packets:243040 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > Interrupt:161 Base address:0xe000 How much long was the card under load ? A few seconds ? The same 1500 bytes mtu is used everywhere and the issue can not be reproduced with a simple ping -f -q -l 64 -s what_you_want aimed at the 8169, right ? [...] > What next? ethtool -d/-S before and after failure, .config and /proc/interrupts. -- Ueimor - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC: 2.6 patch] net/irda/irias_object.c: remove unused exports
On Sun, 2006-04-16 at 19:37 +0100, Alan Cox wrote: > On Sul, 2006-04-16 at 19:46 +0200, Arjan van de Ven wrote: > > > Personally, I don't see what this patch buy us... > > > > all the unused exports in the kernel together make a binary kernel 100Kb > > bigger. It's a case of a lot of little steps I suppose (each export > > taking like 100 to 150 bytes depending on the size of the function name) > > > So why are exports taking us 100-150 bytes, not say 20 which is what I'd > expect ? there is the name, the crc, the address, a module name thingy (which I think is only filled for non-built-in symbols) and I'm sure there's some padding here and there... About 1/3rd of all exports is unused, so killing those is an easy way to gain back the space... - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC: 2.6 patch] net/irda/irias_object.c: remove unused exports
On Sul, 2006-04-16 at 19:46 +0200, Arjan van de Ven wrote: > > Personally, I don't see what this patch buy us... > > all the unused exports in the kernel together make a binary kernel 100Kb > bigger. It's a case of a lot of little steps I suppose (each export > taking like 100 to 150 bytes depending on the size of the function name) So why are exports taking us 100-150 bytes, not say 20 which is what I'd expect ? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC: 2.6 patch] net/irda/irias_object.c: remove unused exports
> Personally, I don't see what this patch buy us... all the unused exports in the kernel together make a binary kernel 100Kb bigger. It's a case of a lot of little steps I suppose (each export taking like 100 to 150 bytes depending on the size of the function name) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-2.6] e1000: fix media_type <-> phy_type thinko
Willy TARREAU wrote:
Recent patch cb764326dff0ee51aca0d450e1a292de65661055 introduced
a thinko in e1000_main.c : e1000_media_type_copper is compared
to hw.phy_type instead of hw.media_type. Original patch proposed
by Jesse Brandeburg was correct, but what has been merged is not.
Indeed this seems like a mistake to me. I'll make sure this is checked
tomorrow with Jeff Kirsher who submitted the original patch.
Auke Kok
---
drivers/net/e1000/e1000_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
3df8a180d50c89a72c28abf37151e38ffda75f39
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index add8dc4..590a456 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -4156,7 +4156,7 @@ e1000_mii_ioctl(struct net_device *netde
spin_unlock_irqrestore(&adapter->stats_lock, flags);
return -EIO;
}
- if (adapter->hw.phy_type == e1000_media_type_copper) {
+ if (adapter->hw.media_type == e1000_media_type_copper) {
switch (data->reg_num) {
case PHY_CTRL:
if (mii_reg & MII_CR_POWER_DOWN)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 locks up in 2.6.16.5
> I'll welcome a complete dmesg after you have recovered through > ifconfig down/up though. _Nothing_ on dmesg. > No problem. One more question: have you enabled NAPI ? If not, you > should. Doesn't seem to make a difference. Here, with it on, after failing it: --- 192.168.99.100 ping statistics --- 1362 packets transmitted, 903 packets received, 33% packet loss round-trip min/avg/max = 0.1/35803.4/65264.8 ms Worse than I thought, to a machine on the same gigabit copper switch... ifconfig eth1: eth1 Link encap:Ethernet HWaddr 00:E0:4C:13:A9:56 inet addr:192.168.99.99 Bcast:192.168.99.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:528416 errors:252 dropped:620 overruns:0 frame:966 TX packets:243040 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 Interrupt:161 Base address:0xe000 ethtool eth1: Settings for eth1: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x0033 (51) Link detected: yes Note, without having thrown traffic through it, I have: PING 192.168.99.100 (192.168.99.100): 56 data bytes 64 bytes from 192.168.99.100: icmp_seq=0 ttl=128 time=0.1 ms 64 bytes from 192.168.99.100: icmp_seq=1 ttl=128 time=0.1 ms 64 bytes from 192.168.99.100: icmp_seq=2 ttl=128 time=0.1 ms 64 bytes from 192.168.99.100: icmp_seq=3 ttl=128 time=0.1 ms --- 192.168.99.100 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.1/0.1/0.1 ms What next? -Tom - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: softmac: semantics of SIOCSIWFREQ
On Sun, 16 Apr 2006, Johannes Berg wrote: > > - If the flag IW_FREQ_FIXED is set, should all activitity > > including scanning only be allowed on this frequency? (Actually > > a better would even be to work with channel/frequency sets. > > These sets would make a lot of sense for parallel scanning > > whith more than one device.) > > Yeah, but that's impossible to code on top of the current wext > structures I'd say. I could be done via an iwpriv. Actually the Personal Telco people, would like to use WLAN devices in parallel to do WAR driving. At least I would like to support the fixed channel semantics. > > SIOCSIWFREQ and SIOCGIWFREQ appear to be good candidates to be > > included in the softmac. If I would have a rough idea, what the > > semantics should be, I would even volunteer to implement it. > > I was thinking of adding all the 'what is this ioctl supposed to do' > things we came up with to the softmac or netdev wiki. Would that be > good/useful, or should we just put it into that driver writers guide? Regarding the wireless extension ioctls, I think the best would be to add kerneldoc comments. Uli -- Ulrich Kunitz - [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: skb diet
On Sunday 16 April 2006 14:56, Hisham Kotry wrote: > > Where would that tag list be stored if you want to remove the > > 40 bytes of ->cb? > > I apologize if I wasn't clear, the tag list would go in a new > skb->tags field replacing the existsing skb->cb array, so the skb > would lose 40-sizeof(void*) bytes wich seems reasonable to me. This means for the common TCP case you would actually need more memory than before - a new pointer and overhead from the tags. Currently we neither need pointer nor tags for anything. Also you would need to complicate alloc_skb to preallocate this memory and complicate the freeing by checking for it and freeing it if it was allocated dynamically (e.g. if a later layer needed it, not the layer that first allocates it you would need to allocate a new buffer later which would then need to be freed) > > > Linux 2.0 did something like this, but that was removed for good > > reasons. Now TCP always clones skbs before sending it out. > > Do you remember what those reasons were? I couldn't find a related > discussion in the archives. I think the BSD mbuf tags approach is > sound enough to justify the move. >From your description so far it seems to only have disadvantages. > > And optimizing for uncommon cases (not TCP) doesn't seem too useful. > > As pointed out by Bert Hubert, there are people who have heavy traffic > on non-tcp connections. It's a small minority compared to TCP users. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 locks up in 2.6.16.5
Thomas A. Oehser <[EMAIL PROTECTED]> : [...] > I tested with everything turned off (no SMP, no swap, no > USB, no firewire, no iptables, no lmsensors, flat 1G memory, > etc. etc. etc.) except the bare minimum (LSI new Megaraid for the > SCSI and SATA raid arrays, both of which use the same driver, EXT3, > VGA console, keyboard, mouse). Also, with everything static and > no modules. Ok, it really looks like a genuine bug. [...] > Changing _nothing_ other than replacing EEPRO100 with R8169 and > vice versa causes it to work perfectly or fail abominably... the > machine always had both nics physically connected, so it was just > the software change of one driver or the other as eth0. > > There was no dmesg output. Then the Rx part of the driver is more screwed than the Tx one. I'll welcome a complete dmesg after you have recovered through ifconfig down/up though. [...] > Note, it will be a day or few before I can retest with ethtool etc., > I have to do my taxes today. No problem. One more question: have you enabled NAPI ? If not, you should. -- Ueimor - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 locks up in 2.6.16.5
> Which motherboard and filesystem do you use ? It's an MSI using EXT3. > Can you send before and after the ping takes 9000 ms: > - ifconfig output > - registers dump via ethtool > > 9000ms seems quite close to the watchdog timeout (6 s) + ping > interval. Complete dmesg and .config will be welcome. I tested with everything turned off (no SMP, no swap, no USB, no firewire, no iptables, no lmsensors, flat 1G memory, etc. etc. etc.) except the bare minimum (LSI new Megaraid for the SCSI and SATA raid arrays, both of which use the same driver, EXT3, VGA console, keyboard, mouse). Also, with everything static and no modules. Changing _nothing_ other than replacing EEPRO100 with R8169 and vice versa causes it to work perfectly or fail abominably... the machine always had both nics physically connected, so it was just the software change of one driver or the other as eth0. There was no dmesg output. Note, one thing I have noticed- it always failed when the load was coming from the same machine. Perhaps the packets from that machine have something about them that particularly spasms the driver? I'll look at what nic and driver that machine is using. Note, it will be a day or few before I can retest with ethtool etc., I have to do my taxes today. -Thanks, -Tom - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: skb diet
> Where would that tag list be stored if you want to remove the > 40 bytes of ->cb? I apologize if I wasn't clear, the tag list would go in a new skb->tags field replacing the existsing skb->cb array, so the skb would lose 40-sizeof(void*) bytes wich seems reasonable to me. > Linux 2.0 did something like this, but that was removed for good > reasons. Now TCP always clones skbs before sending it out. Do you remember what those reasons were? I couldn't find a related discussion in the archives. I think the BSD mbuf tags approach is sound enough to justify the move. > And optimizing for uncommon cases (not TCP) doesn't seem too useful. As pointed out by Bert Hubert, there are people who have heavy traffic on non-tcp connections. Thanks, Hisham - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
softmac: semantics of SIOCSIWFREQ
[breaking out to a new thread so discussion on this doesn't get too hidden, CC Jean since he designed this] > - Is SIOCSIWFREQ allowed while associated? No idea. > - If the flag IW_FREQ_FIXED is set, should all activitity > including scanning only be allowed on this frequency? (Actually > a better would even be to work with channel/frequency sets. > These sets would make a lot of sense for parallel scanning > whith more than one device.) Yeah, but that's impossible to code on top of the current wext structures I'd say. > - Is there any use of the control, if the frequency is not fixed? Good question :) > SIOCSIWFREQ and SIOCGIWFREQ appear to be good candidates to be > included in the softmac. If I would have a rough idea, what the > semantics should be, I would even volunteer to implement it. Yes, they definitely could/should be moved into softmac, but when writing softmac I had no real incentive to do it because I didn't want to dig up the info for all the above points :) I was thinking of adding all the 'what is this ioctl supposed to do' things we came up with to the softmac or netdev wiki. Would that be good/useful, or should we just put it into that driver writers guide? johannes signature.asc Description: This is a digitally signed message part
Re: skb diet
On Sat, Apr 15, 2006 at 09:22:01PM +0200, Andi Kleen wrote: > And optimizing for uncommon cases (not TCP) doesn't seem too useful. There are servers that do tens of megabits of UDP these days (think VoIP, or in my case, DNS), so it not that uncommon. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
softmac: semantics of SIOCSIWFREQ
Hi, I'm just reviewing the zd1211 code and I'm wondering about the semantics of SIOCSIWFREQ and actually, what is good for. It looks like that softmac's set_channel can be called at any time and will ignore any settings of SIOCSIWFREQ even it is has been given the flag IW_FREQ_FIXED. Following questions come to mind: - Is SIOCSIWFREQ allowed while associated? - If the flag IW_FREQ_FIXED is set, should all activitity including scanning only be allowed on this frequency? (Actually a better would even be to work with channel/frequency sets. These sets would make a lot of sense for parallel scanning whith more than one device.) - Is there any use of the control, if the frequency is not fixed? SIOCSIWFREQ and SIOCGIWFREQ appear to be good candidates to be included in the softmac. If I would have a rough idea, what the semantics should be, I would even volunteer to implement it. Uli -- Ulrich Kunitz - [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: fixing sk_stream_rfree()
Hi David:
I've been flying on and off for the last two days so I only saw this now.
On Fri, Apr 14, 2006 at 08:59:27PM -0700, David S. Miller wrote:
>
> Herbert, as you may have noticed we found some missing
> locking in sk_stream_rfree(). It could explain the
> "!sk_forward_alloc" BUG() we thought was caused by e1000's
> TSO implementation and the Intel folks have provided enough
> datapoints to prove that it is indeed not an e1000 specific
> problem.
Great eyes! Yes that bug seems to have been around forever. I'll
look over the patch tomorrow as right now I'm still on west-coast
time :)
I have one niggling doubt though as to why turning off TSO seems
to cure the problem for people. Perhaps it'll become clearer
tomorrow morning when I look at it again :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
