From: "David S. Miller" <davem@davemloft.net>
To: netdev@vger.kernel.org
Cc: "David S . Miller" <davem@davemloft.net>
Subject: [RFC v2 PATCH 00/11] net: Significantly shrink the size of routes.
Date: Tue, 31 Oct 2017 23:10:43 +0900 [thread overview]
Message-ID: <20171031141054.9954-1-davem@davemloft.net> (raw)
Through a combination of several things, our route structures are
larger than they need to be.
Mostly this stems from having members in dst_entry which are only used
by one class of routes. So the majority of the work in this series is
about "un-commoning" these members and pushing them into the type
specific structures.
Unfortunately, IPSEC needed the most surgery. The majority of the
changes here had to do with bundle creation and management.
The other issue is the refcount alignment in dst_entry. Once we get
rid of the not-so-common members, it really opens the door to removing
that alignment entirely.
I think the new layout looks really nice, so I'll reproduce it here:
struct net_device *dev;
struct dst_ops *ops;
unsigned long _metrics;
unsigned long expires;
struct xfrm_state *xfrm;
int (*input)(struct sk_buff *);
int (*output)(struct net *net, struct sock *sk, struct sk_buff *skb);
unsigned short flags;
short obsolete;
unsigned short header_len;
unsigned short trailer_len;
atomic_t __refcnt;
int __use;
unsigned long lastuse;
struct lwtunnel_state *lwtstate;
struct rcu_head rcu_head;
short error;
short __pad;
__u32 tclassid;
This is a rough draft, so there are still some problems to resolve.
In particular, the refcount alignment is only sorted out on 64-bit at
this time. It shouldn't be too hard to either fix 32-bit or decide
that we don't care so much these days or can lower the target
alignment there to 32-bytes rather than 64-bytes.
So, the good news:
1) struct dst_entry shrinks from 160 to 112 bytes.
2) struct rtable shrinks from 216 to 168 bytes.
3) struct rt6_info shrinks from 384 to 320 bytes.
Enjoy.
v2:
Collapse some patches logically based upon feedback.
Fix the strange patch #7.
Signed-off-by: David S. Miller <davem@davemloft.net>
next reply other threads:[~2017-10-31 14:20 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-31 14:10 David S. Miller [this message]
2017-10-31 14:10 ` [RFC v2 PATCH 01/11] net: dst->rt_next is unused David S. Miller
2017-10-31 18:36 ` Eric Dumazet
2017-10-31 14:10 ` [RFC v2 PATCH 02/11] decnet: Move dn_next into decnet route structure David S. Miller
2017-10-31 18:36 ` Eric Dumazet
2017-10-31 14:10 ` [RFC v2 PATCH 03/11] ipv6: Move rt6_next from dst_entry into ipv6 " David S. Miller
2017-10-31 18:37 ` Eric Dumazet
2017-10-31 14:10 ` [RFC v2 PATCH 04/11] net: Create and use new helper xfrm_dst_child() David S. Miller
2017-10-31 18:39 ` Eric Dumazet
2017-11-01 2:07 ` David Miller
2017-10-31 14:10 ` [RFC v2 PATCH 05/11] ipsec: Create and use new helpers for dst child access David S. Miller
2017-10-31 18:40 ` Eric Dumazet
2017-10-31 14:10 ` [RFC v2 PATCH 06/11] xfrm: Move child route linkage into xfrm_dst David S. Miller
2017-10-31 18:42 ` Eric Dumazet
2017-10-31 14:10 ` [RFC v2 PATCH 07/11] ipv6: Move dst->from into struct rt6_info David S. Miller
2017-10-31 18:47 ` Eric Dumazet
2017-10-31 14:10 ` [RFC v2 PATCH 08/11] xfrm: Move dst->path into struct xfrm_dst David S. Miller
2017-10-31 18:49 ` Eric Dumazet
2017-10-31 14:10 ` [RFC v2 PATCH 09/11] net: Rearrange dst_entry layout to avoid useless padding David S. Miller
2017-10-31 18:49 ` Eric Dumazet
2017-10-31 14:10 ` [RFC v2 PATCH 10/11] xfrm: Stop using dst->next in bundle construction David S. Miller
2017-10-31 18:52 ` Eric Dumazet
2017-10-31 14:10 ` [RFC v2 PATCH 11/11] net: Remove dst->next David S. Miller
2017-10-31 18:52 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171031141054.9954-1-davem@davemloft.net \
--to=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).