From: Patrick McHardy <kaber@trash.net>
To: Horms <horms@verge.net.au>
Cc: Ken Brownfield <krb@irridia.com>,
Roberto Nibali <ratz@drugphish.ch>,
netfilter-devel@lists.netfilter.org,
Farid Sarwari <fsarwari@exchangesolutions.com>,
Julian Anastasov <ja@ssi.bg>, David Black <dave@jamsoft.com>,
Joseph Mack NA3T <jmack@wm7d.net>,
David Miller <davem@davemloft.net>
Subject: Re: LVS-NAT and source routing
Date: Sun, 10 Sep 2006 11:54:24 +0200 [thread overview]
Message-ID: <4503E0D0.7090004@trash.net> (raw)
In-Reply-To: <20060904033754.GA13845@verge.net.au>
Horms wrote:
> On Tue, Aug 29, 2006 at 11:06:37AM +0200, Patrick McHardy wrote:
>
>>ip_route_me_harder is meant for the opposite case, rerouting locally
>>originating packets as if they were forwarded (if the source is
>>non-local). For your case just calling ip_route_output_key should be
>>faster since it saves the inet_addr_type call. I think nf_ip_reroute
>>doesn't help much since you always seem to change the source address,
>>but you could make the whole thing depend on CONFIG_IP_MULTIPLE_TABLES.
>
>
> I took a look into this. It seems that the real key is to avoid
> uneccesary calls to inet_addr_type(). But it seems that the rest
> of ip_route_me_harder() really is needed for ip_vs. If that isn't
> correct, please set me straight.
>
> But if it is correct, it really does mean a fair ammount of duplicated
> code going into ip_vs_core.c. I wonder if a better option would be
> to allow the addr_type to be passed to ip_route_me_harder(). I have
> a patch below which expresses this idea. It has the nice advantage
> of offering the scope for other callers to supply the addr_type if it
> is known, though I am not sure that this can be the case.
Usually not, but your patch looks fine anyway. We might even be able
to remove the largely duplicated route_reverse() in ipt_REJECT if
we use LL_MAX_HEADER instead of LL_RESERVED_SPACE for the RST packet
(since we would need to route after allocating the packet and
reversing the addresses).
next prev parent reply other threads:[~2006-09-10 9:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-29 7:37 LVS-NAT and source routing Horms
2006-08-29 9:06 ` Patrick McHardy
2006-08-29 9:31 ` David Miller
2006-08-29 12:52 ` Patrick McHardy
2006-08-29 9:40 ` Horms
2006-09-04 3:37 ` Horms
2006-09-10 9:54 ` Patrick McHardy [this message]
2006-09-10 13:48 ` Horms
2006-09-15 4:34 ` Patrick McHardy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4503E0D0.7090004@trash.net \
--to=kaber@trash.net \
--cc=dave@jamsoft.com \
--cc=davem@davemloft.net \
--cc=fsarwari@exchangesolutions.com \
--cc=horms@verge.net.au \
--cc=ja@ssi.bg \
--cc=jmack@wm7d.net \
--cc=krb@irridia.com \
--cc=netfilter-devel@lists.netfilter.org \
--cc=ratz@drugphish.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.