From: Andy Furniss <andy.furniss@dsl.pipex.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] ESFQ?
Date: Wed, 12 Jan 2005 01:08:42 +0000 [thread overview]
Message-ID: <41E4789A.2060301@dsl.pipex.com> (raw)
In-Reply-To: <41DAB1B4.6030902@expertron.co.za>
Stephen Hemminger wrote:
> On Tue, 11 Jan 2005 23:06:27 +0000
> Andy Furniss <andy.furniss@dsl.pipex.com> wrote:
>
>
>>Thomas Graf wrote:
>>
>>>* Andy Furniss <41E3F088.6060708@dsl.pipex.com> 2005-01-11 15:28
>>>
>>>
>>>>diff -urN linux-2.6.10.orig/include/linux/pkt_sched.h linux-2.6.10/include/linux/pkt_sched.h
>>>>@@ -136,6 +143,7 @@
>>>> __u32 limit; /* Maximal packets in queue */
>>>> unsigned divisor; /* Hash divisor */
>>>> unsigned flows; /* Maximal number of flows */
>>>>+ unsigned hash_kind; /* Hash function to use for flow identification */
>>>>};
>>>
>>>
>>>This breaks compatibility to older iproute2 versions
>>>compiled with older header versions (not including
>>>the additional 4 octets). sch_sfq.c:
>>>
>>> if (opt->rta_len < RTA_LENGTH(sizeof(*ctl)))
>>> return -EINVAL;
>>
>>I did wonder if it could just come out now that iproute2 uses its own
>>pkt_sched.h.
>>
>>Just to be sure I understand - it's a risk that always existed eg.
>>before Stephen maintained iproute2, when it compiled against kernel
>>headers. If I patched kernel and failed to compile new tc/had old tc
>>ahead in path etc. then sfq would be broken.
>>
>>So if you patch make sure you build and use new tc do tc -V / check you
>>don't have an old one in /sbin as iproute2's make install uses /usr/sbin
>>by default.
>>
>
>
> We need to maintain binary compatibility so that old command with latest
> kernel, and new command works with old kernel. That restricts message formats.
>
> But not source compatibility for iproute2, the iproute2 package needs to be self-contained
> and not depend on external (kernel) headers that may or may not be up to date.
>
> Also, older version of iproute2 compiled with current kernel headers
> should be supported. I would rather see all versions of iproute2 tarball's
> as self contained and not depend on kernel headers.
>
Ahh - I think I see what you mean.
If esfq wants to get into kernel then it has to become a completly new
queue and not mess with sfq options at all.
Andy.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
prev parent reply other threads:[~2005-01-12 1:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-04 15:09 [LARTC] ESFQ? Justin Schoeman
2005-01-04 18:04 ` Jonathan Day
2005-01-05 7:18 ` Justin Schoeman
2005-01-05 8:20 ` Andy Furniss
2005-01-05 8:46 ` Justin Schoeman
2005-01-11 15:28 ` Andy Furniss
2005-01-11 15:33 ` Brian Carrig
2005-01-11 15:51 ` Justin Schoeman
2005-01-11 20:38 ` Thomas Graf
2005-01-11 23:06 ` Andy Furniss
2005-01-12 0:21 ` Stephen Hemminger
2005-01-12 1:08 ` Andy Furniss [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41E4789A.2060301@dsl.pipex.com \
--to=andy.furniss@dsl.pipex.com \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox