From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Wed, 12 Jan 2005 01:08:42 +0000 Subject: Re: [LARTC] ESFQ? Message-Id: <41E4789A.2060301@dsl.pipex.com> List-Id: References: <41DAB1B4.6030902@expertron.co.za> In-Reply-To: <41DAB1B4.6030902@expertron.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org Stephen Hemminger wrote: > On Tue, 11 Jan 2005 23:06:27 +0000 > Andy Furniss 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/