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@xxxxxxxxxxxx> To: hadi@xxxxxxxxxx Cc: Stephen Hemminger <shemminger@xxxxxxxx>, netdev@xxxxxxxxxxxxxxx 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. _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
