On Thu, 2004-02-12 at 04:46, Julian Anastasov wrote:
> > If you make another get it goes via fast path.
> > The disappointing part is this feature has a lot of potential
> > if it works "correctly" (imagine being able to populate route cache
> > before packet arrives and not needing for packet to go via slow path).
> I'm not sure I understand your idea, may be you will try
> it one day :)
We can take this offline.
> > I am indifferent about the above (and it may be complicating things).
> I'll have to test it first because it can reduce the
> proxy_queue usage up to 3 times which can be desired in some
> setups, we have linear search there.
That would be great. If you can show a claer benefit, should be fine.
> > Some of your features are fine except they may be a little extreme.
> > Note, this code has been to work well for years, the minimalist
> > approach to features would be the best approach.
> I hope it will continue to work but in a fair way :)
Thats what i am hoping for. Sometimes i just dont touch code
unnecessarily because it may have strange side effects; look at that
tunnel problem posted yesterday for example - some change an inequality
sign in the net sched code and ipip tunnels get affected.
> ok, we are the final of this, I have prepared a change log:
> At this point I do not know how to optimize this patch and
> all changes look valid to me. arp_proxy-2.6.2-1.diff is still the
> latest version but I have to check the proxy_queue optimization.
> To make the code more readable may we can move the (IN_DEV_FORWARD(in_dev))
> body at the end of arp_process. And I'll do more tests in the following
> I know you prefer to live with the old behaviour. I'm not
> sure if we reorder the old code it will look more readable while
> supporting the main new features. And I'm not going to push this if
> we do not have consensus on the implementation. Let me know if
> you have a better version of this change.
Post the patch and i will test it in my environment and make sure it
doesnt break anything here. My interest are two cases: default setup and
proxy_delay being 0.