* Re: [PATCH] Disable TSO for non standard qdiscs
From: Andi Kleen @ 2008-02-01 4:36 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Waskiewicz Jr, Peter P, Andi Kleen,
Patrick McHardy, Stephen
In-Reply-To: <20080131231045.GA5543@ghostprotocols.net>
> Well, it could be just that when using such qdiscs TSO would be
> disabled, but the user could override this by using ethtool after
> loading the qdiscs.
If anything TC, not ethtool. Do you have an useful scenario where
GSO makes sense with TBF et.al.?
-Andi
^ permalink raw reply
* Re: [PATCH] Disable TSO for non standard qdiscs
From: Patrick McHardy @ 2008-02-01 4:26 UTC (permalink / raw)
To: Waskiewicz Jr, Peter P
Cc: Arnaldo Carvalho de Melo, Andi Kleen, Stephen Hemminger, netdev
In-Reply-To: <D5C1322C3E673F459512FB59E0DDC3290133D2A0@orsmsx414.amr.corp.intel.com>
Waskiewicz Jr, Peter P wrote:
>> Well, it could be just that when using such qdiscs TSO would be
>> disabled, but the user could override this by using ethtool after
>> loading the qdiscs.
>
> I still disagree with this. The qdisc should not cause anything to happen to feature flags on the device. It's the scheduling layer and really shouldn't care about what features the device supports or not. If someone has an issue with a feature hurting performance or causing odd behavior when using a qdisc, then they should disable the feature on the device using the appropriate tools provided. If it's the qdisc causing issues, then either the qdisc needs to be fixed, or it should be documented what features are recommended to be on and off with the qdisc. I don't agree that the scheduling layer should affect features on an underlying device.
Andi's patch made the TSO capable flag a property of the
qdisc (not the ops), so it could still be explicitly
configured by the user.
^ permalink raw reply
* Re: [PATCH] Disable TSO for non standard qdiscs
From: Andi Kleen @ 2008-02-01 5:01 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Andi Kleen, Waskiewicz Jr, Peter P, Patrick McHardy,
Stephen Hemminger, netdev
In-Reply-To: <47A230A8.7080100@gmail.com>
On Thu, Jan 31, 2008 at 09:33:44PM +0100, Jarek Poplawski wrote:
> Andi Kleen wrote, On 01/31/2008 08:34 PM:
>
> >> TSO by nature is bursty. But disabling TSO without the option of having
> >> it on or off to me seems to aggressive. If someone is using a qdisc
> >> that TSO is interfering with the effectiveness of the traffic shaping,
> >> then they should turn off TSO via ethtool on the target device. Some
> >
> > The philosophical problem I have with this suggestion is that I expect
> > that the large majority of users will be more happy with disabled TSO
> > if they use non standard qdiscs and defaults that do not fit
> > the majority use case are bad.
>
>
> If you mean the large majority of the large minority of users, who use
> non standard qdiscs - I agree - this is really the philosophical problem!
[....] Sorry if you had a point in this email I missed it.
-Andi
^ permalink raw reply
* Re: [PATCH 0/5] ehea checkpatch fixups
From: Doug Maxey @ 2008-02-01 4:35 UTC (permalink / raw)
To: Nathan Lynch
Cc: Doug Maxey, Jeff Garzik, Linux PowerPC List, netdev,
Paul Mackerras, Jan-Bernd Themann
In-Reply-To: <20080201030542.GX14201@localdomain>
On Thu, 31 Jan 2008 21:05:42 CST, Nathan Lynch wrote:
> Doug Maxey wrote:
> >
> > A small set of fixups for checkpatch.
> >
> > Based on upstream pull from a few hours ago.
>
> Er, ehea doesn't even build right now[1], maybe that could get fixed
> first? :-)
>
> [1] http://lkml.org/lkml/2008/1/28/337
For sure these won't break it any worse. ;) Think of these more as a
janitorial thing vs. structural.
Doesn't gregkh's patch work? At least for the interim?
Jan-Bernd,
What tools are looking in sysfs? distro scripts? I don't see any link
between ethtool and the driver (other than the driver internal bits).
Am I missing something obvious?
++doug
^ permalink raw reply
* [PATCH] vlan tag match
From: Stephen Hemminger @ 2008-02-01 5:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Patrick McHardy
In-Reply-To: <20080131.194644.03127203.davem@davemloft.net>
Provide a way to use tc filters on vlan tag even if tag is buried in
skb due to hardware acceleration.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
include/linux/pkt_cls.h | 3 ++-
include/linux/tc_ematch/tc_em_meta.h | 1 +
net/sched/em_meta.c | 17 +++++++++++++++++
3 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/include/linux/pkt_cls.h b/include/linux/pkt_cls.h
index 1c1dba9..40fac8c 100644
--- a/include/linux/pkt_cls.h
+++ b/include/linux/pkt_cls.h
@@ -459,7 +459,8 @@ enum
#define TCF_EM_U32 3
#define TCF_EM_META 4
#define TCF_EM_TEXT 5
-#define TCF_EM_MAX 5
+#define TCF_EM_VLAN 6
+#define TCF_EM_MAX 6
enum
{
diff --git a/include/linux/tc_ematch/tc_em_meta.h b/include/linux/tc_ematch/tc_em_meta.h
index e21937c..c50d2ba 100644
--- a/include/linux/tc_ematch/tc_em_meta.h
+++ b/include/linux/tc_ematch/tc_em_meta.h
@@ -81,6 +81,7 @@ enum
TCF_META_ID_SK_SNDTIMEO,
TCF_META_ID_SK_SENDMSG_OFF,
TCF_META_ID_SK_WRITE_PENDING,
+ TCF_META_ID_VLAN_TAG,
__TCF_META_ID_MAX
};
#define TCF_META_ID_MAX (__TCF_META_ID_MAX - 1)
diff --git a/net/sched/em_meta.c b/net/sched/em_meta.c
index a1e5619..9c2ec19 100644
--- a/net/sched/em_meta.c
+++ b/net/sched/em_meta.c
@@ -65,6 +65,7 @@
#include <linux/string.h>
#include <linux/skbuff.h>
#include <linux/random.h>
+#include <linux/if_vlan.h>
#include <linux/tc_ematch/tc_em_meta.h>
#include <net/dst.h>
#include <net/route.h>
@@ -170,6 +171,21 @@ META_COLLECTOR(var_dev)
}
/**************************************************************************
+ * vlan tag
+ **************************************************************************/
+
+META_COLLECTOR(int_vlan_tag)
+{
+ unsigned short tag;
+ if (vlan_get_tag(skb, &tag) < 0)
+ *err = -1;
+ else
+ dst->value = tag;
+}
+
+
+
+/**************************************************************************
* skb attributes
**************************************************************************/
@@ -520,6 +536,7 @@ static struct meta_ops __meta_ops[TCF_META_TYPE_MAX+1][TCF_META_ID_MAX+1] = {
[META_ID(SK_SNDTIMEO)] = META_FUNC(int_sk_sndtimeo),
[META_ID(SK_SENDMSG_OFF)] = META_FUNC(int_sk_sendmsg_off),
[META_ID(SK_WRITE_PENDING)] = META_FUNC(int_sk_write_pend),
+ [META_ID(VLAN_TAG)] = META_FUNC(int_vlan_tag),
}
};
--
1.5.3.8
^ permalink raw reply related
* Re: [PATCH] vlan tag match
From: Patrick McHardy @ 2008-02-01 5:34 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20080131210732.25f42884@extreme>
Stephen Hemminger wrote:
> Provide a way to use tc filters on vlan tag even if tag is buried in
> skb due to hardware acceleration.
Looks reasonable. Would you like to add the same feature to the
flow classifier?
^ permalink raw reply
* Re: [PATCH] vlan tag match
From: Stephen Hemminger @ 2008-02-01 5:50 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David Miller, netdev
In-Reply-To: <47A2AF6A.1060200@trash.net>
On Fri, 01 Feb 2008 06:34:34 +0100
Patrick McHardy <kaber@trash.net> wrote:
> Stephen Hemminger wrote:
> > Provide a way to use tc filters on vlan tag even if tag is buried in
> > skb due to hardware acceleration.
>
> Looks reasonable. Would you like to add the same feature to the
> flow classifier?
>
Yes, that would be good.
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply
* Re: e1000 full-duplex TCP performance well below wire speed
From: Bill Fink @ 2008-02-01 6:27 UTC (permalink / raw)
To: Bruce Allen
Cc: Kok, Auke, Brandeburg, Jesse, netdev, Carsten Aulbert,
Henning Fehrmann, Bruce Allen
In-Reply-To: <Pine.LNX.4.63.0801311340270.14403@trinity.phys.uwm.edu>
On Thu, 31 Jan 2008, Bruce Allen wrote:
> >> Based on the discussion in this thread, I am inclined to believe that
> >> lack of PCI-e bus bandwidth is NOT the issue. The theory is that the
> >> extra packet handling associated with TCP acknowledgements are pushing
> >> the PCI-e x1 bus past its limits. However the evidence seems to show
> >> otherwise:
> >>
> >> (1) Bill Fink has reported the same problem on a NIC with a 133 MHz
> >> 64-bit PCI connection. That connection can transfer data at 8Gb/s.
> >
> > That was even a PCI-X connection, which is known to have extremely good latency
> > numbers, IIRC better than PCI-e? (?) which could account for a lot of the
> > latency-induced lower performance...
> >
> > also, 82573's are _not_ a serverpart and were not designed for this
> > usage. 82546's are and that really does make a difference.
>
> I'm confused. It DOESN'T make a difference! Using 'server grade' 82546's
> on a PCI-X bus, Bill Fink reports the SAME loss of throughput with TCP
> full duplex that we see on a 'consumer grade' 82573 attached to a PCI-e x1
> bus.
>
> Just like us, when Bill goes from TCP to UDP, he gets wire speed back.
Good. I thought it was just me who was confused by Auke's reply. :-)
Yes, I get the same type of reduced TCP performance behavior on a
bidirectional test that Bruce has seen, even though I'm using the
better 82546 GigE NIC on a faster 64-bit/133-MHz PCI-X bus. I also
don't think bus bandwidth is an issue, but I am curious if there
are any known papers on typical PCI-X/PCI-E bus overhead on network
transfers, either bulk data transfers with large packets or more
transaction or video based applications using smaller packets.
I started musing if once one side's transmitter got the upper hand,
it might somehow defer the processing of received packets, causing
the resultant ACKs to be delayed and thus further slowing down the
other end's transmitter. I began to wonder if the txqueuelen could
have an affect on the TCP performance behavior. I normally have
the txqueuelen set to 10000 for 10-GigE testing, so decided to run
a test with txqueuelen set to 200 (actually settled on this value
through some experimentation). Here is a typical result:
[bill@chance4 ~]$ nuttcp -f-beta -Itx -w2m 192.168.6.79 & nuttcp -f-beta -Irx -r -w2m 192.168.6.79
tx: 1120.6345 MB / 10.07 sec = 933.4042 Mbps 12 %TX 9 %RX 0 retrans
rx: 1104.3081 MB / 10.09 sec = 917.7365 Mbps 12 %TX 11 %RX 0 retrans
This is significantly better, but there was more variability in the
results. The above was with TSO enabled. I also then ran a test
with TSO disabled, with the following typical result:
[bill@chance4 ~]$ nuttcp -f-beta -Itx -w2m 192.168.6.79 & nuttcp -f-beta -Irx -r -w2m 192.168.6.79
tx: 1119.4749 MB / 10.05 sec = 934.2922 Mbps 13 %TX 9 %RX 0 retrans
rx: 1131.7334 MB / 10.05 sec = 944.8437 Mbps 15 %TX 12 %RX 0 retrans
This was a little better yet and getting closer to expected results.
Jesse Brandeburg mentioned in another post that there were known
performance issues with the version of the e1000 driver I'm using.
I recognized that the kernel/driver versions I was using were rather
old, but it was what I had available to do a quick test with. Those
particular systems are in a remote location so I have to be careful
with messing with their network drivers. I do have some other test
systems at work that I might be able to try with newer kernels
and/or drivers or maybe even with other vendor's GigE NICs, but
I won't be back to work until early next week sometime.
-Bill
^ permalink raw reply
* Re: [IPROUTE 02/02]: Add flow classifier support
From: Stephen Hemminger @ 2008-02-01 6:28 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Linux Netdev List
In-Reply-To: <47A20C63.6030806@trash.net>
applied both to git
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply
* Re: [PATCH] Disable TSO for non standard qdiscs
From: Glen Turner @ 2008-02-01 6:35 UTC (permalink / raw)
To: Andi Kleen
Cc: Waskiewicz Jr, Peter P, Patrick McHardy, Stephen Hemminger,
netdev
In-Reply-To: <20080131193406.GH4671@one.firstfloor.org>
On Thu, 2008-01-31 at 20:34 +0100, Andi Kleen wrote:
> The philosophical problem I have with this suggestion is that I expect
> that the large majority of users will be more happy with disabled TSO
> if they use non standard qdiscs and defaults that do not fit
> the majority use case are bad.
I wouldn't be so fast to assume that all users need an exact playout
rate, as people seem to do fine with the 8Kbps playout steps in Cisco
IOS. A nerd-knob which expresses user's preference in the
accuracy/performance trade-off would be nice.
The problem with ethtool is that it's a non-obvious nerd knob. At
the least the ethtool documentation should be updated to indicate that
activating TSO effects tc accuracy.
Best wishes, Glen
[a network engineer]
^ permalink raw reply
* [PATCH] add if_addrlabel.h to sanitized headers
From: Stephen Hemminger @ 2008-02-01 6:37 UTC (permalink / raw)
Cc: netdev
In-Reply-To: <20080128.210222.07062540.yoshfuji@linux-ipv6.org>
if_addrlabel.h is needed for iproute2 usage.
Signed-off-by: Stephen Hemminger <stephen.hemminger@vyatta.com>
---
include/linux/Kbuild | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index 85b2482..ce9d0fd 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -218,6 +218,7 @@ unifdef-y += i2c-dev.h
unifdef-y += icmp.h
unifdef-y += icmpv6.h
unifdef-y += if_addr.h
+unifdef-y += if_addrlabel.h
unifdef-y += if_arp.h
unifdef-y += if_bridge.h
unifdef-y += if_ec.h
--
1.5.3.8
^ permalink raw reply related
* Re: [PATCH] Disable TSO for non standard qdiscs
From: Patrick McHardy @ 2008-02-01 6:46 UTC (permalink / raw)
To: Glen Turner; +Cc: Andi Kleen, Waskiewicz Jr, Peter P, Stephen Hemminger, netdev
In-Reply-To: <1201847738.17656.5.camel@roma.44ansell.gdt.id.au>
Glen Turner wrote:
> On Thu, 2008-01-31 at 20:34 +0100, Andi Kleen wrote:
>
>> The philosophical problem I have with this suggestion is that I expect
>> that the large majority of users will be more happy with disabled TSO
>> if they use non standard qdiscs and defaults that do not fit
>> the majority use case are bad.
>
> I wouldn't be so fast to assume that all users need an exact playout
> rate, as people seem to do fine with the 8Kbps playout steps in Cisco
> IOS. A nerd-knob which expresses user's preference in the
> accuracy/performance trade-off would be nice.
>
> The problem with ethtool is that it's a non-obvious nerd knob. At
> the least the ethtool documentation should be updated to indicate that
> activating TSO effects tc accuracy.
I agree with Andi, most user neither know nor care about TSO.
It should work properly by default and optimizations should
be explicitly configured. This is especially true if you
consider the common userbase of qdiscs - which is mostly
slow DSL lines, cablemodems etc.
^ permalink raw reply
* Re: [2.6 patch] rtnetlink.c: #if 0 no longer used functions
From: Patrick McHardy @ 2008-02-01 7:00 UTC (permalink / raw)
To: David Miller; +Cc: bunk, netdev
In-Reply-To: <20080131.171751.192428440.davem@davemloft.net>
David Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Wed, 30 Jan 2008 21:04:33 +0100
>
>> Adrian Bunk wrote:
>>> This patch #if 0's the following no longer used functions:
>>> - rtattr_parse()
>>> - rtattr_strlcpy()
>>> - __rtattr_parse_nested_compat()
>>>
>> Please remove them instead.
>
> Agreed.
The rtattr_parse_nested_compat macro can also go away.
^ permalink raw reply
* Re: [PATCH] Disable TSO for non standard qdiscs
From: Andi Kleen @ 2008-02-01 7:46 UTC (permalink / raw)
To: Glen Turner
Cc: Andi Kleen, Waskiewicz Jr, Peter P, Patrick McHardy,
Stephen Hemminger, netdev
In-Reply-To: <1201847738.17656.5.camel@roma.44ansell.gdt.id.au>
> The problem with ethtool is that it's a non-obvious nerd knob. At
> the least the ethtool documentation should be updated to indicate that
> activating TSO effects tc accuracy.
TSO tends to be activated by default in the driver; very few people who use it
do even know that ethtool exist or what TSO is.
-Andi
^ permalink raw reply
* Re: [PATCH] Disable TSO for non standard qdiscs
From: Patrick McHardy @ 2008-02-01 7:25 UTC (permalink / raw)
To: Andi Kleen; +Cc: Glen Turner, Waskiewicz Jr, Peter P, Stephen Hemminger, netdev
In-Reply-To: <20080201074600.GA12644@one.firstfloor.org>
Andi Kleen wrote:
>> The problem with ethtool is that it's a non-obvious nerd knob. At
>> the least the ethtool documentation should be updated to indicate that
>> activating TSO effects tc accuracy.
>
> TSO tends to be activated by default in the driver; very few people who use it
> do even know that ethtool exist or what TSO is.
Indeed. As an example of an unknowing user, this discussion made me
check whether my cablemodem device (on which I'm using HFSC) uses
TSO :)
^ permalink raw reply
* Re: [PATCH] Disable TSO for non standard qdiscs
From: Jarek Poplawski @ 2008-02-01 7:42 UTC (permalink / raw)
To: Andi Kleen
Cc: Waskiewicz Jr, Peter P, Patrick McHardy, Stephen Hemminger,
netdev
In-Reply-To: <47A2540D.8090003@gmail.com>
On 01-02-2008 00:04, Jarek Poplawski wrote:
...
> ...On the other hand, with this DSL argument from the sub-thread you
> could be quite right: if this "everyone" wants to use one NIC for
> both high speed local network and such a DSL, then learning ethtool
> could be not enough...
...But, on the other hand, in this case the realization seems to be
wrong: probably still all locally created packets will be treated
the same - or I miss something?
Jarek P.
^ permalink raw reply
* Re: [1/2] POHMELFS - network filesystem with local coherent cache.
From: Evgeniy Polyakov @ 2008-02-01 7:39 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: linux-kernel, netdev, linux-fsdevel
In-Reply-To: <Pine.LNX.4.64.0802010159460.4864@fbirervta.pbzchgretzou.qr>
Hi.
On Fri, Feb 01, 2008 at 02:04:39AM +0100, Jan Engelhardt (jengelh@computergmbh.de) wrote:
> >POHMELFS stands for Parallel Optimized Host Message Exchange
> >Layered File System. It allows to mount remote servers to local
> >directory via network. This filesystem supports local caching
> >and writeback flushing.
> >POHMELFS is a brick in a future distributed filesystem.
>
> A brick is usually something that is in the way -
> Or you also say "the user has bricked his machine"
> when it's quite unusable :)
> Hope you did not mean /that/.
No, this brick as a building block :)
> >This set includes two patches:
> > * network filesystem with write-through cache (slow, but works with
> > remote userspace server)
> > * hack to show how local cache works and how faster it is compared
> > to async NFS (see below). hack disables writeback flush and
> > performs local allocation of the objects only.
> >
> >Now, some vaporware aka food for thoughts and your brains.
> >
> >A small benchmark of the local cached mode (above hack):
> >
> >$ time tar -xf /home/zbr/threading.tar
> >
> > POHMELFS NFS v3 (async)
> >real 0m0.043s 0m1.679s
> >
> >Which is damn 40 times!
>
> Needs a bigger data set to compare. But what is much more
> important: does it use a single port for networing, or some
> firewall-unfriendly-by-default multiple dynamic-port-allocation
> like NFS?
It uses single port, configurable at mount time.
POHMELFS client can connect to different addresses (including ipv6) and
via different protocols (like sctp). Metadata server will provide that
information dynamically, so pohmelfs client will be able to connect to
different nodes and perform operations in parallell.
> >Next task is to think about how to generically solve the problem with
> >syncing local changes with remote server, when remote server maintains inodes with
> >completely different numbers.
> >This, among others, will allow offline work with automatic syncing after reconnect.
>
> What will happen when both nodes change an inode in disconnected state?
> Which inode wins out?
Who will be online first. Second node will be told that there is a
merge collision and it has to be resolved by hands.
> >This is not intended for inclusion, CRFS by Zach Brown is a bit ahead of POHMELFS,
> >but it is not generic enough (because of above problem), works only with BTRFS,
> >and was closed by Oracle so far :)
>
> btrfs is all we need :p
Well, at least it has some very interesting ideas.
Although there are things which are not that good imho, time will
show, maybe there will be another state-of-the-art filesystem at the
moment...
This was for information.
> Where's the parallelism that is advertised by the "POH" in pohmelfs?
First, clients work with local caches and sync them either in writeback
or via cache coherency algorithm. This work is effectively parallel.
Second, pohmelfs as in distributed filesystem is developed as a transport
layer to eliminate mount operation for each different node, so that
after client asks for data it would be just sent to different server.
This allows to make parallel transactions. Essentially it looks like
mounting different remote server to virtual directory working with it,
except that connection setup should be done not at mount time, but at
run time.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: e1000 full-duplex TCP performance well below wire speed
From: Bruce Allen @ 2008-02-01 7:54 UTC (permalink / raw)
To: Bill Fink
Cc: Kok, Auke, Brandeburg, Jesse, netdev, Carsten Aulbert,
Henning Fehrmann, Bruce Allen
In-Reply-To: <20080201012732.232b7859.billfink@mindspring.com>
Hi Bill,
> I started musing if once one side's transmitter got the upper hand, it
> might somehow defer the processing of received packets, causing the
> resultant ACKs to be delayed and thus further slowing down the other
> end's transmitter. I began to wonder if the txqueuelen could have an
> affect on the TCP performance behavior. I normally have the txqueuelen
> set to 10000 for 10-GigE testing, so decided to run a test with
> txqueuelen set to 200 (actually settled on this value through some
> experimentation). Here is a typical result:
>
> [bill@chance4 ~]$ nuttcp -f-beta -Itx -w2m 192.168.6.79 & nuttcp -f-beta -Irx -r -w2m 192.168.6.79
> tx: 1120.6345 MB / 10.07 sec = 933.4042 Mbps 12 %TX 9 %RX 0 retrans
> rx: 1104.3081 MB / 10.09 sec = 917.7365 Mbps 12 %TX 11 %RX 0 retrans
>
> This is significantly better, but there was more variability in the
> results. The above was with TSO enabled. I also then ran a test
> with TSO disabled, with the following typical result:
>
> [bill@chance4 ~]$ nuttcp -f-beta -Itx -w2m 192.168.6.79 & nuttcp -f-beta -Irx -r -w2m 192.168.6.79
> tx: 1119.4749 MB / 10.05 sec = 934.2922 Mbps 13 %TX 9 %RX 0 retrans
> rx: 1131.7334 MB / 10.05 sec = 944.8437 Mbps 15 %TX 12 %RX 0 retrans
>
> This was a little better yet and getting closer to expected results.
We'll also try changing txqueuelen. I have not looked, but I suppose that
this is set to the default value of 1000. We'd be delighted to see
full-duplex performance that was consistent and greater than 900 Mb/s x 2.
> I do have some other test systems at work that I might be able to try
> with newer kernels and/or drivers or maybe even with other vendor's GigE
> NICs, but I won't be back to work until early next week sometime.
Bill, we'd be happy to give you root access to a couple of our systems
here if you want to do additional testing. We can put the latest drivers
on them (and reboot if/as needed). If you want to do this, please just
send an ssh public key to Carsten.
Cheers,
Bruce
^ permalink raw reply
* RE: [PATCH] Disable TSO for non standard qdiscs
From: Waskiewicz Jr, Peter P @ 2008-02-01 9:28 UTC (permalink / raw)
To: Jarek Poplawski, Andi Kleen; +Cc: Patrick McHardy, Stephen Hemminger, netdev
In-Reply-To: <20080201074239.GA2897@ff.dom.local>
> ...But, on the other hand, in this case the realization seems to be
> wrong: probably still all locally created packets will be
> treated the same - or I miss something?
>
> Jarek P.
The TCP layer will generate TSO packets based on the kernel socket
features associated with the flow. So if you have two devices, one
supporting TSO, the other not, then the flows associated with the
non-TSO device will not have their packets built for TSO. This has no
bearing on the device supporting TSO, which its feature flags will
propogate into the kernel socket for that flow, and cause any TCP flows
to that device to be TSO packets. So in a nutshell, disabling TSO is on
a per-device level, not a global switch.
-PJ Waskiewicz
^ permalink raw reply
* RE: [PATCH] Disable TSO for non standard qdiscs
From: Waskiewicz Jr, Peter P @ 2008-02-01 9:37 UTC (permalink / raw)
To: Patrick McHardy, Andi Kleen; +Cc: Glen Turner, Stephen Hemminger, netdev
In-Reply-To: <47A2C985.30409@trash.net>
> Indeed. As an example of an unknowing user, this discussion
> made me check whether my cablemodem device (on which I'm
> using HFSC) uses TSO :)
The TSO defer logic is based on your congestion window and current
window size. So the actual frame sizes hitting your NIC attached to
your DSL probably aren't anywhere near 64KB, but probably more in line
with whatever your window size is for DSL.
The bottom line is TSO saves CPU cycles. If we want to make it go away
because of a traffic shaping qdisc interfering, then that's fine. I
just don't think a TSO option should be added to the scheduler layer,
since it already exists in the ethtool layer. Asking a user to type
'ethtool -k <devicename> tso off' is probably going to be much easier
than setting an option on your qdisc through tc to turn TSO back on.
I think we're having more of a disagreement of what is considered the
"normal case" user. If you are on a slow link, such as a DSL/cable
line, your TCP window/congestion window aren't going to be big enough to
generate large TSO's, so what is the issue? But disabling TSO, say on a
10 GbE link, can cut throughput by half (I have data on 8-core machines
with 10 GbE with/without TSO if you're interested). Even on a
single-core machine with a 1GbE link can have bad performance hits. So
this is why I'm so concerned about a proposal to turn off TSO outside of
the current established methods of using ethtool. Rather than educating
the user about how to turn TSO back on using tc if they want it, educate
them why they may want to consider turning TSO off in certain
configurations. And I don't consider any user effectively using a TBF
qdisc someone incapable of understanding how to use ethtool.
Cheers,
-PJ Waskiewicz
^ permalink raw reply
* Re: [PATCH] Disable TSO for non standard qdiscs
From: Patrick McHardy @ 2008-02-01 9:56 UTC (permalink / raw)
To: Waskiewicz Jr, Peter P; +Cc: Andi Kleen, Glen Turner, Stephen Hemminger, netdev
In-Reply-To: <D5C1322C3E673F459512FB59E0DDC32904737A42@orsmsx414.amr.corp.intel.com>
Waskiewicz Jr, Peter P wrote:
>> Indeed. As an example of an unknowing user, this discussion
>> made me check whether my cablemodem device (on which I'm
>> using HFSC) uses TSO :)
>
> The TSO defer logic is based on your congestion window and current
> window size. So the actual frame sizes hitting your NIC attached to
> your DSL probably aren't anywhere near 64KB, but probably more in line
> with whatever your window size is for DSL.
>
> The bottom line is TSO saves CPU cycles. If we want to make it go away
> because of a traffic shaping qdisc interfering, then that's fine. I
> just don't think a TSO option should be added to the scheduler layer,
> since it already exists in the ethtool layer. Asking a user to type
> 'ethtool -k <devicename> tso off' is probably going to be much easier
> than setting an option on your qdisc through tc to turn TSO back on.
>
> I think we're having more of a disagreement of what is considered the
> "normal case" user. If you are on a slow link, such as a DSL/cable
> line, your TCP window/congestion window aren't going to be big enough to
> generate large TSO's, so what is the issue? But disabling TSO, say on a
> 10 GbE link, can cut throughput by half (I have data on 8-core machines
> with 10 GbE with/without TSO if you're interested). Even on a
> single-core machine with a 1GbE link can have bad performance hits. So
> this is why I'm so concerned about a proposal to turn off TSO outside of
> the current established methods of using ethtool. Rather than educating
> the user about how to turn TSO back on using tc if they want it, educate
> them why they may want to consider turning TSO off in certain
> configurations. And I don't consider any user effectively using a TBF
> qdisc someone incapable of understanding how to use ethtool.
We don't want to disable TSO for cases where it makes sense, but
who is using TBF on 10GbE? The point is that most users of qdiscs
which are incapable of dealing with TSO without hacks or special
configuration probably don't care, and 10GbE users know about
ethtool *and* don't use TBF or HTB (which are probably the only
qdiscs which actually have problems, maybe also CBQ).
^ permalink raw reply
* oops with ipcomp
From: Beschorner Daniel @ 2008-02-01 10:09 UTC (permalink / raw)
To: netdev; +Cc: Herbert Xu
One more issue with 2.6.24, some hours after I reactivated ipcomp with
Herb's 2 patches.
The httpd log shows a http request per esp tunnel at oops time.
Don't know whether it is for network or compression guys, so I started
posting here.
Daniel
Unable to handle kernel paging request at ffffc200000fb000 RIP:
[<ffffffff8031b8f0>] deflate_slow+0x40/0x400
PGD 7f845067 PUD 7f846067 PMD 7f847067 PTE 0
Oops: 0000 [1] SMP
CPU 0
Modules linked in:
Pid: 9136, comm: httpd Not tainted 2.6.24 #2
RIP: 0010:[<ffffffff8031b8f0>] [<ffffffff8031b8f0>]
deflate_slow+0x40/0x400
RSP: 0018:ffff81002ad35938 EFLAGS: 00010206
RAX: 0000000000000000 RBX: ffffc200000b9000 RCX: 00000000000408d8
RDX: ffffc200000ba728 RSI: 0000000000000000 RDI: 0000000000005f65
RBP: 00000000000008d4 R08: 0000000000003dae R09: 0000000000001800
R10: 0000000000000010 R11: ffffc200000b94bc R12: 00000000000001ad
R13: 0000000000000005 R14: 0000000000000000 R15: ffffc20000097000
FS: 00002b00bb68b190(0000) GS:ffffffff805a8000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc200000fb000 CR3: 000000002ac82000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process httpd (pid: 9136, threadinfo ffff81002ad34000, task
ffff81007d2d4080)
Stack: ffff810042f3f710 ffff81007dfb0700 0000000000000005
ffffc200000b9000
ffff81007de89000 ffffffff8031c25d 0000000000000000 ffff81007dfb0700
ffff81007dfb06c0 ffff81007de890a8 000000000000010a ffffffff802ff351
Call Trace:
[<ffffffff8031c25d>] zlib_deflate+0x10d/0x330
[<ffffffff802ff351>] deflate_compress+0x91/0xb0
[<ffffffff804771b8>] ipcomp_output+0x98/0x1e0
[<ffffffff80489ef6>] xfrm_output+0x116/0x1e0
[<ffffffff80482dc4>] xfrm4_output_finish2+0x44/0x1e0
[<ffffffff80483075>] xfrm4_output+0x55/0x60
[<ffffffff80445989>] ip_queue_xmit+0x209/0x450
[<ffffffff8049b0d0>] thread_return+0x3d/0x54d
[<ffffffff8023b094>] lock_timer_base+0x34/0x70
[<ffffffff80456dcf>] tcp_transmit_skb+0x40f/0x7c0
[<ffffffff80458aae>] __tcp_push_pending_frames+0x11e/0x940
[<ffffffff8044cb8e>] tcp_sendmsg+0x81e/0xc40
[<ffffffff80291e3f>] dput+0x1f/0x130
[<ffffffff80410b01>] sock_aio_write+0x111/0x120
[<ffffffff804109f0>] sock_aio_write+0x0/0x120
[<ffffffff8027f95b>] do_sync_readv_writev+0xcb/0x110
[<ffffffff80246850>] autoremove_wake_function+0x0/0x30
[<ffffffff8027fb99>] do_sync_read+0xd9/0x120
[<ffffffff80287941>] permission+0x61/0x100
[<ffffffff8027f7bd>] rw_copy_check_uvector+0x9d/0x130
[<ffffffff802800a2>] do_readv_writev+0xe2/0x210
[<ffffffff8027e1ba>] do_filp_open+0x3a/0x50
[<ffffffff802806e3>] sys_writev+0x53/0x90
[<ffffffff8020bb3e>] system_call+0x7e/0x83
Code: 0f b6 14 0a 31 d0 23 43 74 48 8b 53 60 89 43 68 89 c0 0f b7
RIP [<ffffffff8031b8f0>] deflate_slow+0x40/0x400
RSP <ffff81002ad35938>
CR2: ffffc200000fb000
---[ end trace cfeb10aa23b54939 ]---
^ permalink raw reply
* [PATCH] ieee80211: fix section mismatch warning
From: Sam Ravnborg @ 2008-02-01 11:52 UTC (permalink / raw)
To: netdev, Johannes Berg, John W. Linville, David S. Miller
Fix the following warnings:
WARNING: net/built-in.o(.init.text+0xd6c0): Section mismatch in reference from the function ieee80211_init() to the function .exit.text:rc80211_simple_exit()
WARNING: net/built-in.o(.init.text+0xd6c5): Section mismatch in reference from the function ieee80211_init() to the function .exit.text:rc80211_pid_exit()
The fix was simple - I just did as modpost told me and removed the
wrong __exit annotation of rc80211_simple_exit and rc80211_pid_exit.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: David S. Miller <davem@davemloft.net>
---
With this patch my allyesconfig build on x86 (64 bit)
is section mismatch clean in net/
Sam
diff --git a/net/mac80211/rc80211_pid_algo.c b/net/mac80211/rc80211_pid_algo.c
index 554c4ba..c339571 100644
--- a/net/mac80211/rc80211_pid_algo.c
+++ b/net/mac80211/rc80211_pid_algo.c
@@ -538,7 +538,7 @@ int __init rc80211_pid_init(void)
return ieee80211_rate_control_register(&mac80211_rcpid);
}
-void __exit rc80211_pid_exit(void)
+void rc80211_pid_exit(void)
{
ieee80211_rate_control_unregister(&mac80211_rcpid);
}
diff --git a/net/mac80211/rc80211_simple.c b/net/mac80211/rc80211_simple.c
index 934676d..9a78b11 100644
--- a/net/mac80211/rc80211_simple.c
+++ b/net/mac80211/rc80211_simple.c
@@ -389,7 +389,7 @@ int __init rc80211_simple_init(void)
return ieee80211_rate_control_register(&mac80211_rcsimple);
}
-void __exit rc80211_simple_exit(void)
+void rc80211_simple_exit(void)
{
ieee80211_rate_control_unregister(&mac80211_rcsimple);
}
^ permalink raw reply related
* Re: [PATCH] Disable TSO for non standard qdiscs
From: jamal @ 2008-02-01 12:06 UTC (permalink / raw)
To: Patrick McHardy
Cc: Waskiewicz Jr, Peter P, Andi Kleen, Glen Turner,
Stephen Hemminger, netdev
In-Reply-To: <47A2ECE9.5000103@trash.net>
On Fri, 2008-01-02 at 10:56 +0100, Patrick McHardy wrote:
> We don't want to disable TSO for cases where it makes sense, but
> who is using TBF on 10GbE? The point is that most users of qdiscs
> which are incapable of dealing with TSO without hacks or special
> configuration probably don't care, and 10GbE users know about
> ethtool *and* don't use TBF or HTB (which are probably the only
> qdiscs which actually have problems, maybe also CBQ).
Right - Essentially it is a usability issue:
People who know how to use TSO (Peter for example) will be clueful
enough to turn it on. Which means the default should be to protect the
clueless and turn it off.
On Andis approach:
Turning TSO off at netdev registration time with a warning will be a
cleaner IMO. Or alternatively introducing a kernel-config "I know what
TSO is" option which is then used at netdev registration. From a
usability perspective it would make more sense to just keep ethtool as
the only way to configure TSO.
[I recently spent a few days helping someone debug a problem with IFB
because he was redirecting packets from an TSO netdevice and occasionaly
some multi-packet will be missed in the calculation; my answer was "turn
off TSO"; so there are more use cases for this TSO issue].
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] ieee80211: fix section mismatch warning
From: Johannes Berg @ 2008-02-01 12:07 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: netdev, John W. Linville, David S. Miller, linux-wireless
In-Reply-To: <20080201115206.GA12678@uranus.ravnborg.org>
[-- Attachment #1: Type: text/plain, Size: 1908 bytes --]
On Fri, 2008-02-01 at 12:52 +0100, Sam Ravnborg wrote:
> Fix the following warnings:
> WARNING: net/built-in.o(.init.text+0xd6c0): Section mismatch in reference from the function ieee80211_init() to the function .exit.text:rc80211_simple_exit()
> WARNING: net/built-in.o(.init.text+0xd6c5): Section mismatch in reference from the function ieee80211_init() to the function .exit.text:rc80211_pid_exit()
>
> The fix was simple - I just did as modpost told me and removed the
> wrong __exit annotation of rc80211_simple_exit and rc80211_pid_exit.
Heh, I just sent the same patch.
> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
> Cc: Johannes Berg <johannes@sipsolutions.net>
> Cc: John W. Linville <linville@tuxdriver.com>
> Cc: David S. Miller <davem@davemloft.net>
> ---
>
> With this patch my allyesconfig build on x86 (64 bit)
> is section mismatch clean in net/
>
> Sam
>
> diff --git a/net/mac80211/rc80211_pid_algo.c b/net/mac80211/rc80211_pid_algo.c
> index 554c4ba..c339571 100644
> --- a/net/mac80211/rc80211_pid_algo.c
> +++ b/net/mac80211/rc80211_pid_algo.c
> @@ -538,7 +538,7 @@ int __init rc80211_pid_init(void)
> return ieee80211_rate_control_register(&mac80211_rcpid);
> }
>
> -void __exit rc80211_pid_exit(void)
> +void rc80211_pid_exit(void)
> {
> ieee80211_rate_control_unregister(&mac80211_rcpid);
> }
> diff --git a/net/mac80211/rc80211_simple.c b/net/mac80211/rc80211_simple.c
> index 934676d..9a78b11 100644
> --- a/net/mac80211/rc80211_simple.c
> +++ b/net/mac80211/rc80211_simple.c
> @@ -389,7 +389,7 @@ int __init rc80211_simple_init(void)
> return ieee80211_rate_control_register(&mac80211_rcsimple);
> }
>
> -void __exit rc80211_simple_exit(void)
> +void rc80211_simple_exit(void)
> {
> ieee80211_rate_control_unregister(&mac80211_rcsimple);
> }
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ 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