Prev: hwmon: (coretemp) Get TjMax value from MSR
Next: atl1c: Add AR8151 v2 support and change L0s/L1 routine
From: Paul Mackerras on 29 May 2010 03:00
On Wed, Mar 31, 2010 at 11:03:44AM +0100, Ben McKeegan wrote:

> I needed to do something similar a while back and I took a very
> different approach, which I think is more flexible. Rather than
> implement a new round-robin scheduler I simply introduced a target
> minimum fragment size into the fragment size calculation, as a per
> bundle parameter that can be configured via a new ioctl. This
> modifies the algorithm so that it tries to limit the number of
> fragments such that each fragment is at least the minimum size. If
> the minimum size is greater than the packet size it will not be
> fragmented all but will instead just get sent down the next
> available channel.
>
> A pppd plugin generates the ioctl call allowing this to be tweaked
> per connection. It is more flexible in that you can still have the
> larger packets fragmented if you wish.

I like this a lot better than the other proposed patch. It adds less
code because it uses the fact that ppp_mp_explode() already has a
round-robin capability using the ppp->nxchan field, plus it provides a
way to control it per bundle via pppd.

If you fix up the indentation issues (2-space indent in some of the
added code -- if you're using emacs, set c-basic-offset to 8), I'll
ack it and hopefully DaveM will pick it up.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: David Miller on 1 Jun 2010 18:20
From: Richard Hartmann <richih.mailinglist(a)gmail.com>
Date: Tue, 1 Jun 2010 13:28:59 +0200

> Maybe not a bug in the Linux kernel itself, but certainly in the real world
> that exists around Linux. Similar to how a change to a device driver that
> is needed to work around broken hardware is a bug fix, imo.

It's not the same situation at all.

It is easier to fix misconfigured products that exist because of
software and configurations than it is to fix a physical piece of
hardware.

So you could work around it if you wanted to.

I definitely don't see this as -stable material, as a result. We will
push it to net-next-2.6 and it will thus hit 2.6.36 as previously
mentioned.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: hwmon: (coretemp) Get TjMax value from MSR
Next: atl1c: Add AR8151 v2 support and change L0s/L1 routine