[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1444189699.9555.25.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Tue, 06 Oct 2015 20:48:19 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: David Miller <davem@...emloft.net>,
netfilter-devel@...r.kernel.org, netdev@...r.kernel.org,
Nicolas Dichtel <nicolas.dichtel@...nd.com>,
lvs-devel@...r.kernel.org
Subject: Re: [PATCH net-next 10/15] ipv4: Cache net in ip_build_and_send_pkt
and ip_queue_xmit
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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists