On Tue, 2015-10-06 at 22:26 -0500, Eric W. Biederman wrote: > So what I am really reading it for is ip_local_out which I change to > take a struct net a few patches later in the series. The patches that > changes everything is noticably cleaner and easier to review with these > couple of patches pulling struct net into it's own variable ahead of > time, and ip_build_and_send_pkt does call ip_local_out unconditionally. > > I am in the process of figuring out how to compute net once in the > output path and just passing it through so I don't need to compute net > from dst->dev. As when the dust settles I hope to allow for a dst->dev > in another network namespace. So that routes with a destination device > in another network namespace will allow for something simpler and faster > than ipvlan that achieves a very similar effect. > > In this case to achieve what you are looking for, for cache line > friendliness I believe we would need to pass net in from > tcp_v4_send_synack, and it's cousins in dccp. Yes, something that can be done later. > > skc_net does seem firmly in the first cache line of sockets so it does > look like any of the the reads to inet_sock that we do perform would > hit the same cache line. > > To recap. I store net in a variable because I start using it > unconditionally a few patches later. The only way I can see to avoid > hitting the cold cache line is to pass net into ip_build_and_send_pkt. > > Do you think passing net into ip_build_and_send_pkt is the sensible way > to address your performance concern? Or do you have issues with my > passing of net through the output path? I have no issues, but was pointing out this particular path, that might be optimized later, no worries. Thanks. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
