Re: [net-next-2.6 PATCH 1/7] xfrm: introduce basic mark infrastructure

[jamal <hadi@cyberus.ca>]

On Mon, 2010-02-15 at 18:21 +0100, Patrick McHardy wrote:

> The xfrm route lookup doesn't use the packet mark.

I see.
Is there a historical reason why it hasnt been used this way?
Reminds me of the reverse path patch i sent a while back that
caused havoc.. (mark wasnt being used in the reverse path either)

> A couple of years ago I used this in a multipath setup, which
> was using CONNMARK to persistently bind connections (tunnels
> in this case) to a route after the first selection.

Sounds like a reasonable feature to me.

> The problem with backwards compatibility is that people using
> marks for multipath routing are most likely not expecting the
> mark to suddenly take effect for IPsec tunnel routing.

The main reason it works ok for ipsec/policy-routing is because
user space essentially pins down the kernel path. Could you
not solve it via some user space daemon? First packet/event
to user space, download policies and wait until it expires or
route/tunnel goes down to react..

One of the problems maybe the semantics of what a general purpose
tag like mark being left to either the programmer (as in connmark)
or the admin (tc) - so building a general purpose daemon would have
to enforce some semantic to work ok.

cheers,
jamal