> On 23 May, 2018, at 9:44 pm, David Miller <da...@davemloft.net> wrote: > > I'd much rather you do something NAT method agnostic, like save > or compute the necessary information on ingress and then later > use it on egress.
We were under the impression that conntrack was the cleanest and most correct way to convey this information between qdiscs. Frankly it's difficult to see how else we could do it without major complications. Remember that it takes two different qdiscs to implement ingress and egress on the same physical interface, and there's no obvious logical link between them - especially since the ingress one has to be attached to an ifb, not to the actual interface, because there's no native support for ingress qdiscs. What's more, there's no information (besides conntrack) at ingress about the "inside" address of NATted traffic. There might be some residual information for egress traffic, but communicating that to the ingress side feels very much like we need to reimplement something very like conntrack. If not supporting "alternative" NAT mechanisms that don't register their data in conntrack is the penalty, it's one I personally can live with. - Jonathan Morton _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
