On Mon, 2006-03-13 at 22:39 -0500, jamal 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.
OK. But what I can replace "sample" with is directly specifying the hash using the ht option. This requires me to manually calculate the hash. Since "sample" hasn't worked since 2.6, I guess I must be the only person on the planet who isn't using "ht". I will also that this to mean that I am almost certainly the only person on the planet hashing more than one byte. If you were you hashing more than one byte, then who wants to manually calculate a hash? Not me anyway - that is what computers are for. Unless, of course, you happen to be the author of the said hashing algorithm. Then you know that manually calculating it is trivial in 2.6 - it can be done by inspection. Making the user manually calculate the hash puts the said author in a bit of a bind, of course. It now means every shell script out there effectively knows, and depends on knowing, the hash algorithm used by the kernel. Ergo, it can't be changed without causing huge amounts of pain. You might get away with it between major releases, 2.4 to 2.6 say. But now it appears the kernel has done away with major releases, so changing the hash function becomes a near impossibility. Personally, I would never of allowed the user to specify the bucket using the ht option, and reserved the right to changing the hash algorithm in the kernel and user space tools whenever I wanted to. It is still possible to move in that direction, btw. You could assume the bucket passed to the ht option is a single byte value (as calculated by sample u3 VALUE 0xff say), which is to be hashed. It would work because the current hash functions on single byte values are identities. > 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. It is controversial with you, and possibly Stephen (I haven't really understood why he rejected the patch, he hasn't replied yet to my last email), and me of course. As you point out, we seem to be the only people in the Universe who care. You didn't really answer my question below about why you dislike the patch. I can tell you why I want it. I run production boxes, some with 2.4 and some with 2.6. I am currently carrying patches for tc. I would rather not do that - I don't get security updates for example. Purely selfish reasons I know - but isn't that how these things are meant to work - if you have an itch to scratch...? > > 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. I didn't mean to come across like that. Sorry. > 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. You may of well asked me to find the holy grail, I think. :(. > 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. Assuming you are not swayed by the arguments above, I think I have lost this one. I presume you have no objections to changing "tc" to use the 2.6 hash and leave it at that. Yes? Before I can submit a patch to do that, you have to decide whether reverting to the 2.4 hash function is a good idea. If so it is the kernel that has to change, not "tc". - 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
