netdev - Re: [PATCH net-next 10/15] ipv4: Cache net in ip_build_and_send_pkt and ip_queue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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