|
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 lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|
