Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[RFC\s+net\-next\]\s+ipv6\:\s+Use\s+destination\s+address\s+determined\s+by\s+IPVS\s*$/: 28 ]

Total 28 documents matching your query.

21. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Eric Dumazet <eric.dumazet@xxxxxxxxx>
Date: Tue, 15 Oct 2013 19:40:59 -0700
Ah well... No, its not appropriate to grow sk_buff by 16 bytes, sorry. You could not change struct inet6_skb_parm, but define IP6CB as a compound struct ip6cb { struct inet6_skb_parm foo; struct in6_
/html/lvs-devel/2013-10/msg00016.html (11,149 bytes)

22. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Simon Horman <horms@xxxxxxxxxxxx>
Date: Wed, 16 Oct 2013 11:14:49 +0900
I think it should be possible to solve that using the IP6CB() approach that Eric suggested. Hopefully we can make that approach fly. -- To unsubscribe from this list: send the line "unsubscribe lvs-d
/html/lvs-devel/2013-10/msg00015.html (12,357 bytes)

23. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Simon Horman <horms@xxxxxxxxxxxx>
Date: Wed, 16 Oct 2013 11:13:06 +0900
That does seem very promising but while implementing it I hit a problem. struct tcp_skb_cb includes a field of type struct inet6_skb_parm. And expanding struct inet6_skb_parm by 16 bytes means that s
/html/lvs-devel/2013-10/msg00014.html (11,388 bytes)

24. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Hannes Frederic Sowa <hannes@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 16 Oct 2013 02:53:22 +0200
Hmm, that reminds me on the following bug report which would be nice we could solve in one go, too: http://www.spinics.net/lists/netdev/msg250785.html Greetings, Hannes -- To unsubscribe from this li
/html/lvs-devel/2013-10/msg00013.html (11,482 bytes)

25. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Eric Dumazet <eric.dumazet@xxxxxxxxx>
Date: Tue, 15 Oct 2013 17:39:09 -0700
This was to point that between IPVS and ipv6 stack we might have a delay, and daddr was maybe pointed to a freed memory. IP6CB only uses 24 bytes, so I think you would be safe adding 16 bytes. -- To
/html/lvs-devel/2013-10/msg00012.html (10,400 bytes)

26. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Simon Horman <horms@xxxxxxxxxxxx>
Date: Wed, 16 Oct 2013 09:28:07 +0900
I thought of you when I wrote that comment :) I can change that to passing a value if there is a risk the reference could become invalid. To be honest I am more worried that skb->cb might be clobbere
/html/lvs-devel/2013-10/msg00011.html (15,051 bytes)

27. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Eric Dumazet <eric.dumazet@xxxxxxxxx>
Date: Tue, 15 Oct 2013 17:13:46 -0700
Please no ;) So we pass a reference. What guarantee do we have daddr points to valid memory (not already freed/reused) ? I guess things like NFQUEUE could happen ? -- To unsubscribe from this list: s
/html/lvs-devel/2013-10/msg00010.html (14,251 bytes)

28. [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Simon Horman <horms@xxxxxxxxxxxx>
Date: Wed, 16 Oct 2013 09:02:31 +0900
In v3.9 6fd6ce2056de2709 ("ipv6: Do not depend on rt->n in ip6_finish_output2()") changed the behaviour of ip6_finish_output2() such that it creates and uses a neigh entry if none is found. Subsequen
/html/lvs-devel/2013-10/msg00009.html (13,744 bytes)


This search system is powered by Namazu