Magnus Bergroth <bergr...@nordu.net> writes: >> Eric W. Biederman <mailto:ebied...@xmission.com> >> a) I just looked and the kernel netlink protocol does not have a limit. >> The kernel does have a limit but the netlink protocol does not so >> there is no point in exporting a limit in a uapi header, it will >> just be out of date and wrong. >> >> b) I can see in principle bumping up the kernels MAX_LABELS past two >> although I haven't heard those requests, or understand the use cases. >> I don't recall seeing any ducumentation on cases where it is >> desirable to push a lot of labels at once. (Do hardware >> implementations support pushing a lot of labels at once?) >> >> Bumping past 8 seems quite a lot. That starts feeling like people >> trying to break other peoples mpls stacks. That is asking for more >> packet space for labels than ipv6 uses for addresses and ipv6 is way >> oversized. The commonly agreed wisdom is the world only needs 40 to >> 48 bits to route on to reach the entire world. > I think that 8 would be more than enough for most use cases, even 6 or 4 > would be sufficient. I'm looking at doing MPLS source routing based on a > label-stack. Each router in the network will get a set of static routes > that pop the label and sends it out to the next router based on the > label that gets poped. I have no problem compiling a special build with > the MAX_LABELS set to my need. I just noticed that changing only the > MAX_LABELS wasn't enough to get more than 8 labels to work with iproute2 > after changing the kernel "MAX_NEW_LABELS 2" in > include/net/mpls_iptunnel.h and net/mpls/internal.h to a higher > number.
At a practical level in general it doesn't make sense to support special builds. The code rarely get tested and so bit rots. In a situation like this it makes sense to dig in and solve the problem as generally as you can as long as it doesn't cause problems for anything else. Eric
