LVS
lvs-devel
Google
 
Web LinuxVirtualServer.org

Re: [PATCH net-next 06/12] ipvs: optimize dst usage for real server

To: David Miller <davem@xxxxxxxxxxxxx>
Subject: Re: [PATCH net-next 06/12] ipvs: optimize dst usage for real server
Cc: horms@xxxxxxxxxxxx, lvs-devel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxxxxxx
From: Julian Anastasov <ja@xxxxxx>
Date: Thu, 7 Mar 2013 02:14:00 +0200 (EET)
        Hello,

On Wed, 6 Mar 2013, David Miller wrote:

> From: Julian Anastasov <ja@xxxxxx>
> Date: Wed, 6 Mar 2013 23:58:09 +0200 (EET)
> 
> >     There are two choices: __ip_vs_get_out_rt
> > to return refdst as implemented in this patchset or
> > to return dst with additional 'bool *noref' argument,
> > so that caller can decide between skb_dst_set or
> > skb_set_dst_noref. Then may be we will need just
> > a new skb_dst_set_noref_{always,force} func that will
> > contain the old skb_set_dst_noref code, i.e. without
> > dst_hold? Not sure which variant sounds better.
> 
> Both variants are starting to sound equally ugly :-)
> 
> Let me ask about this situation in another way.
> 
> IP input route lookup clients handle this transparently,
> even for routes with next-hop exceptions and nocache
> routes, by passing the SKB into the lookup function and
> there it will sort out whether noref is actually possible.
> 
> Is there a reason that IPVS's route lookup architecture
> can't work this way too?

        May be it is possible, eg. by adding more
arguments to __ip_vs_get_out_rt and moving all dst
checks and icmp_send there. But there are some dst
checks specific to the forwarding method, so I'm not
sure in the end result yet.

        For IPVS, noref is always possible because the
dst_cache var holds reference, even for the NOCACHE case
which is more likely to occur. So, some new variant of
skb_dst_set_noref that supports NOCACHE without dst_hold
is still needed.

Regards

--
Julian Anastasov <ja@xxxxxx>
--
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>