On Tue, 2006-14-03 at 13:16 +1000, Russell Stuart wrote: > On Mon, 2006-03-13 at 21:24 -0500, jamal wrote: [..] > > 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.
Trust me - I understand this stuff;-> (I have described these two to many people). And i will take a look at your doc at some point. What i mean is: that you could achieve the result of stitching hashtables together to direct a packet to eventually reach a terminal node with either scheme. "Sample" is supposed to be more intuitive but you dont need to use it. > 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. > [..] > > 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. > Given that the change is controversial and that other than you or i (and of course Alexey) - I dont know of anybody else who is even aware of this feature; i consider it as an option, yes. > 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. > Agreed. But you didnt seem to agree with this earlier. > 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. > It breaks it for a small number of users - ones who are actually pretty clueful and will be able to do an upgrade. > 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. > If you can find 2 other people who use "sample" in scripts in the manner in which you and i use them (ok maybe i should lower it to 1 other person), then please send me a shipping address and I will send you a gift certificate for a drink of your choice. For the common use of 1 byte (for the cutnpasters out there) i think we agree it is a non-issue. So lets assume a worst case where there is no 2.4.x fix, it is still fine. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
