Hi Lukas, On Wed, Jun 19, 2013 at 02:03:18AM +0200, Lukas Tribus wrote: > Hi! > > I gave the new set-tos option a try, and I noticed two things: > > - addr.to.ss_family is never AF_INET, addr.from.ss_family is what we are > looking for (after this change, it works for IPv4)
I was a bit puzzled wondering why it worked for me, and I found. It only depends on the config, and if you have anything that needs the destination address (logs, transparent, ...) then conn_get_to_addr() is called early and the address is properly set. So I agree with you that it's the from we want here. > - the IPv6 related part is missing (TOS/DSCP has the same meaning in IPv6 > than in IPv4, so if addr.from.ss_family is AF_INET6, we can imho go > ahead and set IPV6_TCLASS from set-tos) It was intentional, as looking at the specs, I really did not feel like we could use the same classes nor the same method to set them. But the DSCP specs are a bit foggy to me so I might have overlooked something. > The attached preliminary diff does those two things (and a small doc fix), > however I need some commentary about: > > - if IPV6_TCLASS is not defined, we abort (even though IP_TOS may be > defined, and IPv4 TOS/DSCP could be set) - is this acceptable? The only > way around this would be a dedicated option for IPv6, but that seems > overkill We sure don't want a dedicated action, but before trying to set the TOS on IPv6, I'd like to be confirmed it uses the same values. > - when haproxy listens on both families with one bind statement, it sees > IPv4 connection in the AF_INET6 family (like ::ffff:10.0.0.3 instead of > 10.0.0.3): when this happens, we set IPV6_TCLASS, but it has no effect. > Probably expected kernel behavior and I believe most of the people use > dedicate (per address-family) sockets anyway. Good point, I didn't think about this case either. I don't even know what method we can use to set the flags in this case. Maybe using the IPv4 method works ? > Let me know what you guys think about this. > > Willy, do you prefer such a diff like this to be splitted in 2 or 3 patches > or as-is? It would probably be better to split at least the technical ones > into different commits (so a git-bisect is more meaningful). I'd prefer several patches. One is a fix (to->from) and can as well include the doc fix. The other one is an improvement that will possibly need to be iteratively reworked later after some testing. Best regards, Willy
