- 1. Re: [PATCH net 0/3] ipv6: use rt6i_gateway as nexthop (score: 1)
- Author: Simon Horman <horms@xxxxxxxxxxxx>
- Date: Mon, 28 Oct 2013 10:28:15 +0900
- Thanks Dave, FWIW, I have verified that these changes resolve the problem that I reported with IPVS that I believe prompted Julian to write these changes. That is IPv6 IPVS-DR once again works with t
- /html/lvs-devel/2013-10/msg00066.html (12,120 bytes)
- 2. Re: [PATCH net 0/3] ipv6: use rt6i_gateway as nexthop (score: 1)
- Author: David Miller <davem@xxxxxxxxxxxxx>
- Date: Mon, 21 Oct 2013 18:40:57 -0400 (EDT)
- I have decided to merge all three patches into -net right now. I've reviewed these patches several times and they look good to me. I'll let them cook upstream for at least a week before submitting th
- /html/lvs-devel/2013-10/msg00053.html (11,300 bytes)
- 3. Re: [PATCH net 0/3] ipv6: use rt6i_gateway as nexthop (score: 1)
- Author: Julian Anastasov <ja@xxxxxx>
- Date: Mon, 21 Oct 2013 23:02:57 +0300 (EEST)
- Hello, Yes, ipv6_addr_type has little price. May be only DNAT and IPSec can complicate such caching. Yes, I checked every site that uses rt6i_gateway but not with the perspective to use rt6_nexthop()
- /html/lvs-devel/2013-10/msg00052.html (12,015 bytes)
- 4. Re: [PATCH net 0/3] ipv6: use rt6i_gateway as nexthop (score: 1)
- Author: Hannes Frederic Sowa <hannes@xxxxxxxxxxxxxxxxxxx>
- Date: Mon, 21 Oct 2013 11:35:41 +0200
- Not related to the patch: That reminds me that Yoshifuji had the idea to cache the results for ipv6_addr_type in IP6CB to avoid calling this function over and over again. Maybe we can do the same for
- /html/lvs-devel/2013-10/msg00051.html (11,536 bytes)
- 5. [PATCH net 0/3] ipv6: use rt6i_gateway as nexthop (score: 1)
- Author: Julian Anastasov <ja@xxxxxx>
- Date: Sun, 20 Oct 2013 15:43:02 +0300
- The following patchset makes sure that rt6i_gateway contains valid nexthop information in all cases, so that we can use different nexthop for sending. The first patch is a simple fix that makes IPVS,
- /html/lvs-devel/2013-10/msg00043.html (12,293 bytes)
This search system is powered by
Namazu