[LARTC] ESFQ?

[Andy Furniss]

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.