LARTC - Mar 2006 - [Fwd: Re: [PATCH] TC: bug fixes to the "sample" clause]

List admins.  Can you fix the issue described below, 
ie jamal''s posts to the lists bouncing, please?


-------- Forwarded Message --------
From: Russell Stuart <russell-lartc@stuart.id.au>
To: hadi@cyberus.ca
Cc: Stephen Hemminger <shemminger@osdl.org>, netdev@vger.kernel.org
Subject: Re: [PATCH] TC: bug fixes to the "sample" clause
Date: Tue, 14 Mar 2006 13:16:52 +1000
On Mon, 2006-03-13 at 21:24 -0500, jamal wrote:
> If you dont mind please stop ccing lartc - they keep bouncing my mail.
OK.  Somebody should fix that.  A kernel net developer
not being able to post to lartc is just plain wrong.
> On Tue, 2006-14-03 at 10:31 +1000, Russell Stuart wrote:
> 
> > Anyway, jokes aside, the situation we have now is the 
> > current "tc" doesn''t work with the current kernel. 
> 
> Slow down:
> The two perceived problematic combos are:
> a) old hash in tc for the case of sample with kernel 2.6 with current
> hash. 
> - This is not a problem if you use a single byte. Usage of anything
> other than one byte is not documented anywhere as you point out.
> Therefore the issue of backward compatibility is not a big deal IMO
> because it is hardly used as a feature.
> 
> People who are brave such as yourself, who go beyond the 1 byte or less
> than a byte can be brave enough to upgrade as well.
Agreed.
> b) new hash (if it is to be upgraded) with 2.4.x
> Again non-issue with 1 byte.  Issues show up if you use > or < 1
byte.
> 
> And besides if you really insist, look at using hashkey - it will work a
> lot better since the dependency is only at the kernel and none at user
> space. 
Hashkey and sample do different things.  Briefly, hashkey is
used to direct a "link" operation to the correct bucket at
runtime, whereas "sample" is used put a u32 filter line in
the correct bucket at "compile time".  If you want more detail
read the doco I wrote.

As it happens, I agree with removing any dependency on the
hashing algorithm at user level - if not at user space.
"tc" lives in user space, and is the exception.  I tend to 
view it like iptables - if you want it to work with the 
latest kernel, get the latest version of iptables.  Ditto 
for "tc".  "tc" hides the details of the kernel.  This
"hiding the details in tc" gives the kernel developers the 
freedom to change the hashing algorithm, and indeed other
details, any time they like.
> [You made assertions that the old hash was better - can we please defer
> that discussion to later and resolve this first? There are many
> variables that you ignored in your derivation (we can discuss what those
> are later)]
OK.
> So my take on this is: 
> either forget about making any changes at all 
And leave the "sample" clause of u32 broken?  I don''t
view that as a reasonable option.  I am surprised you 
do.
> or 
> fix things so going forward they will work(which is the recommendation i
> have made). Backward compatibility is a less important issue for
> something that perhaps a handful of people use (I consider myself a nig
> user of u32 and hardly use this feature).
You said to do two things:

a.  Modify "tc" to use the 2.6 algorithm only.
b.  Modify the 2.4 kernel to use the 2.6 hashing algorithm.

I viewed these two things are part of the same package.
They have to be, otherwise we don''t have a tc in CVS
that works with all maintained kernels.

The issue I have with it is that if I were the 2.4 kernel
maintainer, there is no way I would allow a change that
breaks 2.4 binary compatibility.  So to me, the "package"
is a non-flyer.

Actually, I am having trouble understanding why you dislike 
the utsname patch.  Binary compatibility was broken between 
2.4 and 2.6.  Fine.  So the assumption is the user space 
apps have to deal with it, I presume.  If you don''t like 
dealing with it using utsname, then what other method do 
you suggest we use?

Ignoring the problem and saying it will only effect a few
users isn''t dealing with it.  To me it looks more like
pretending it didn''t happen, in hopes that no-one will 
notice.