LVS
lvs-devel
Google
 
Web LinuxVirtualServer.org

Re: [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS

To: Patrick McHardy <kaber@xxxxxxxxx>
Subject: Re: [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS
Cc: netdev@xxxxxxxxxxxxxxx, Hans Schillstrom <hans@xxxxxxxxxxxxxxx>, lvs-devel@xxxxxxxxxxxxxxx, Julian Anastasov <ja@xxxxxx>, Simon Horman <horms@xxxxxxxxxxxx>, Wensong Zhang <wensong@xxxxxxxxxxxx>, netfilter-devel@xxxxxxxxxxxxxxx
From: Jesper Dangaard Brouer <brouer@xxxxxxxxxx>
Date: Tue, 04 Sep 2012 23:25:18 +0200
On Mon, 20 Aug 2012, Jesper Dangaard Brouer wrote:

[cut]

> This patch contains a lot of API changes.  This is done, to avoid
> the costly scan of finding the IPv6 headers, via ipv6_find_hdr().

(small correction ipv6_find_hdr() is not that costly for the general
case of no exthdrs)

> Finding the IPv6 headers is done as early as possible, and passed
> on as a pointer "struct ip_vs_iphdr *" to the affected functions.

This passing the "struct ip_vs_iphdr" actually makes sense.  It reminds
me of the way netfilter/iptables passes the xt_actions_param to each
rule.  Which contains the same information as ip_vs_iphdr.  (note ipvs
register at hooks at a lower level and don't get passed the
xt_actions_param).

Thus, perhaps we should keep these API changes.  Even if we decide to
optimize ipv6_find_hdr().  (as proposed by my RFC patch)

Perhaps we should consider adding a "family" to ip_vs_iphdr, as is done
in xt_actions_param.  This could help us, with collapsing IPv4 and IPv6
code, but i can see that other structs in IPVS carry this info already,
so not sure its relevant.


--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS, Jesper Dangaard Brouer <=