Oops, sorry about that, I did notice your initial set of speed up patches (that's why I was enthusiastically playing around with large rule sets and became aware of the issue in the first place), but evidently I didn't follow the related thread very closely. I am not familiar enough with the iptables code to decide whether or not chains are always sorted by name in the kernel, and thus will be sorted if you read them back, but if that's the case, of course your method is better, as long as that's always the case... To be honest, I didn't really understand the chain_index code ;) On Wed, Jul 02, 2008 at 10:57:31PM +0200, Jesper Dangaard Brouer wrote: > > I can see from the list that Thomas Jacob <jacob@xxxxxxxxxxxxx>, and I > have just posted patches solving the same issue. > > I promised Patrick that I would work on this issue, and I did. > > Its running on our production servers, and I planned to release the > patch today as it has proven stable on production. I guess Thomas was > just slightly faster than me ;-) > > It was actually already released in the CPAN module IPTables::libiptc > (ver.0.08 released 2008-06-16). > > > We both use binary search, but with two slightly different approaches. > > - My patch uses the existing data structure, and the existing > algorithm for binary searching. > > - Thomas builds a new data structure and implements a new binary > search algorithm. > > I must give Thomas that this binary search algo (taken from wikipedia) > is much more compact than the existing one. > > Guess I cannot judge what patch is the best, as I'm biased... > > -- > To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
signature.asc
Description: Digital signature
