On Tue, 2006-14-03 at 15:05 +1000, Russell Stuart wrote: > On Mon, 2006-03-13 at 22:39 -0500, jamal wrote:
[..] > 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". > Essentially thats what it boils down to - manually/brute-force setup. u32 is not pretty: you need to get down and it does get ugly. So the best way to do this, IMO, is to sit down - knowing what your traffic patterns look like - and draw an optimal maze of hash tables and then connect them together using hashkey. If you are really want to even statically optimize then even go further and define htids. The problem with u32 is it is too powerful and provides too many choices. I have always wished someone would write a wrapper around it and restrict the choices available so that most people wouldnt know how it is even done and it would output an efficient setup for them. > I will also that this to mean that I am almost certainly > the only person on the planet hashing more than one byte. Hey, I am on less 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. > Again this comes to choices - when you have too many it is always a challenge. > 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. > It could - if it can proven to maintain backward compatibility. I think backward compatibility would probably be fine to be defined as "it works with one byte". But you are right. It is a pain. One suggestion Stephen Hemminger had was to transport the hash on a TLV; I am not a big fan of dynamic coding. > 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. > Again choices. Most people wouldnt use hash key or sample. > > 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. > I think that would be even more controversial. We need to have a new classifier - call it newu32 where we can resolve a lot of things learnt from u32. > > > 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...? > Well, the way we strive to have code working in backwards compatible format with any netlink derived code such as is the case with iproute2 is to introduce new TLVs. This way old kernels ignore new ones and new ones can opt to ignore old TLVs. You will never ever see code which says "if this is 2.4.x then x" - it is considered close to blasphemy; more importantly it adds maintainance overhead - imagine if someone changed the hash in the kernel. > > 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? > > indeed. > 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". > I dont agree with reverting the 2.6.x change. In the future if you do prove that the old one is better or a newer one is better then we will revisit given the definition we have of backwards compatibility above. Note, you need a lot more data than the simple example you showed. We can discuss this later etc. I am interested. 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
