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.
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 i
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 simples
> 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 perspec
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
> 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 man
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 s
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 ment
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
> 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 warnin
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
> > wit
> 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, 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, a
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
> 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 prob
> ...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 yo
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 o
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 ethto
> 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 wha
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 cas
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
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 th
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 t
> 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: se
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 anyt
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 wor
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
> 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 real
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
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:
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 v
> 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 u
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 connect
> 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 phi
> My point was that without TSO different submitters will
> interleave their streams (because they compete about the
> qdisc submission) and then you end up with a smooth rate over
> time for all of them.
>
> If you submit in large chunks only (as TSO does) it will
> always be more bursty and
> 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 soc
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 se
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
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 anythi
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 just
> 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
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, 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
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 anything useful
> >with large TSO packets.
>
>
> Someone posted a p
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
> 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]
Mor
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 ove
49 matches
Mail list logo
