On Sun, Feb 03, 2008 at 09:57:10AM +1100, Herbert Xu wrote:
Andi Kleen [EMAIL PROTECTED] wrote:
Then change TBF to use skb_gso_segment? Be careful, the fact that
That doesn't help because it wants to interleave packets
from different streams to get everything fair and smooth. The only
Andi Kleen [EMAIL PROTECTED] wrote:
Then change TBF to use skb_gso_segment? Be careful, the fact that
That doesn't help because it wants to interleave packets
from different streams to get everything fair and smooth. The only
good way to handle that is to split it up and the simplest way
Andi Kleen [EMAIL PROTECTED] wrote:
Hmm, that would probably be possible for TBF, but I'm not sure this can be
really done in a useful way for the more complicated qdiscs. Especially
since they would likely need to turn on/off GSO regularly when dynamic
circumstances change and there is not
...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
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
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
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
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.
DSL windows can be quite large because a
On Fri, 1 Feb 2008 15:34:21 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
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
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
On Fri, Feb 01, 2008 at 01:28:15AM -0800, Waskiewicz Jr, Peter P wrote:
...
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
Does this also imply that JumboFrames interacts badly with these qdiscs?
Or IPoIB with its 65000ish byte MTU?
Correct. Of course it is always relative to the link speed. So if your
link is 10x faster and your packets 10x bigger you can get similarly
smooth shaping.
If the later-in-thread
jamal wrote, On 02/01/2008 01:06 PM:
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
I totally disagree with these POVs:
- 10G cards should be treated by default as 10G cards - not
DSL modems,
and common users shouldn't have to read any warnings or configs to
see this.
- tc with TBF or HTB are professional tools; there should be
added some
warnings to manuals.
On Fri, Feb 01, 2008 at 01:58:30PM -0800, Rick Jones wrote:
Does this also imply that JumboFrames interacts badly with these qdiscs?
Or IPoIB with its 65000ish byte MTU?
Correct. Of course it is always relative to the link speed. So if your
link is 10x faster and your packets 10x bigger
Turning TSO off at netdev registration time with a warning will be a
cleaner IMO. Or alternatively introducing a kernel-config I know what
You mean the qdisc should force TSO off on the underlying device?
TSO is option which is then used at netdev registration. From a
usability perspective
TSO interacts badly with many queueing disciplines because they rely on
reordering packets from different streams and the large TSO packets can
make this difficult. This patch disables TSO for sockets that send over
devices with non standard queueing disciplines. That's anything but noop
or
On Thu, 31 Jan 2008 13:46:32 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
TSO interacts badly with many queueing disciplines because they rely on
reordering packets from different streams and the large TSO packets can
make this difficult. This patch disables TSO for sockets that send over
Fix the broken qdisc instead.
What do you mean? I don't think the qdiscs are broken.
I cannot think of any way how e.g. TBF can do anything useful
with large TSO packets.
-Andi
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More
Andi Kleen wrote:
Fix the broken qdisc instead.
What do you mean? I don't think the qdiscs are broken.
I cannot think of any way how e.g. TBF can do anything useful
with large TSO packets.
Someone posted a patch some time ago to calculate the amount
of tokens needed in max_size portions and
Then change TBF to use skb_gso_segment? Be careful, the fact that
That doesn't help because it wants to interleave packets
from different streams to get everything fair and smooth. The only
good way to handle that is to split it up and the simplest way to do
this is to just tell TCP to not do
Andi Kleen wrote:
Then change TBF to use skb_gso_segment? Be careful, the fact that
That doesn't help because it wants to interleave packets
from different streams to get everything fair and smooth. The only
good way to handle that is to split it up and the simplest way to do
this is to
Andi Kleen wrote:
TSO interacts badly with many queueing disciplines because they rely on
reordering packets from different streams and the large TSO packets can
make this difficult. This patch disables TSO for sockets that send over
devices with non standard queueing disciplines. That's
Stephen Hemminger wrote:
On Thu, 31 Jan 2008 19:37:35 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
On Thu, Jan 31, 2008 at 07:01:00PM +0100, Patrick McHardy wrote:
Andi Kleen wrote:
Fix the broken qdisc instead.
What do you mean? I don't think the qdiscs are broken.
I cannot think of any way
On Thu, Jan 31, 2008 at 07:21:20PM +0100, Patrick McHardy wrote:
Andi Kleen wrote:
Then change TBF to use skb_gso_segment? Be careful, the fact that
That doesn't help because it wants to interleave packets
from different streams to get everything fair and smooth. The only
good way to
On Thu, Jan 31, 2008 at 10:26:19AM -0800, Rick Jones wrote:
Andi Kleen wrote:
TSO interacts badly with many queueing disciplines because they rely on
reordering packets from different streams and the large TSO packets can
make this difficult. This patch disables TSO for sockets that send
On Thu, 31 Jan 2008 19:37:35 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
On Thu, Jan 31, 2008 at 07:01:00PM +0100, Patrick McHardy wrote:
Andi Kleen wrote:
Fix the broken qdisc instead.
What do you mean? I don't think the qdiscs are broken.
I cannot think of any way how e.g. TBF can do
So, at what timescale do people using these qdiscs expect things to
appear smooth? 64KB of data at GbE speeds is something just north of
half a millisecond unless I've botched my units somewhere.
One typical use case for TBF is you talking to a DSL bridge that
is connected using a GBit
Andi Kleen wrote:
On Thu, Jan 31, 2008 at 07:21:20PM +0100, Patrick McHardy wrote:
Andi Kleen wrote:
Then change TBF to use skb_gso_segment? Be careful, the fact that
That doesn't help because it wants to interleave packets
from different streams to get everything fair and smooth. The only
Andi Kleen wrote:
On Thu, Jan 31, 2008 at 10:26:19AM -0800, Rick Jones wrote:
Andi Kleen wrote:
TSO interacts badly with many queueing disciplines because they rely on
reordering packets from different streams and the large TSO packets can
make this difficult. This patch disables TSO for
Andi Kleen wrote:
So, at what timescale do people using these qdiscs expect things to
appear smooth? 64KB of data at GbE speeds is something just north of
half a millisecond unless I've botched my units somewhere.
One typical use case for TBF is you talking to a DSL bridge that
is
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
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.
Basically you're suggesting that nearly everyone using
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
Jarek Poplawski wrote, On 01/31/2008 09:33 PM:
Andi Kleen wrote, On 01/31/2008 08:34 PM
...
Basically you're suggesting that nearly everyone using tc should learn about
another obscure command
...On the other hand, with this DSL argument from the sub-thread you
could be quite right: if
Em Thu, Jan 31, 2008 at 11:39:55AM -0800, Waskiewicz Jr, Peter P escreveu:
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
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
Rick Jones wrote:
then the qdisc could/should place a cap on the size of a 'TSO' based on
the bitrate (and perhaps input as to how much time any one burst of
data should be allowed to consume on the network) and pass that up the
stack? right now you seem to be proposing what is effectively a
On Thu, Jan 31, 2008 at 11:14:34AM -0800, Rick Jones wrote:
Sounds like the functionality needs to be in the DSL bridge :) (or the
router in the same case) Particularly since it might be getting used
by more than one host on the GbE switch.
Possible, but it is not usually in the real world.
On Thu, Jan 31, 2008 at 03:42:54PM -0800, 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
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
--
To unsubscribe from this list: send
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
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
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
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
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
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
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
48 matches
Mail list logo
