From: roopa <roopa@cumulusnetworks.com>
To: Robert Shearman <rshearma@brocade.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH net-next 2/2] mpls: reduce memory usage of routes
Date: Tue, 27 Oct 2015 18:39:20 -0700 [thread overview]
Message-ID: <56302748.7050209@cumulusnetworks.com> (raw)
In-Reply-To: <1445906256-14927-3-git-send-email-rshearma@brocade.com>
On 10/26/15, 5:37 PM, Robert Shearman wrote:
> Nexthops for MPLS routes have a via address field sized for the
> largest via address that is expected, which is 32 bytes. This means
> that in the most common case of having ipv4 via addresses, 28 bytes of
> memory more than required are used per nexthop. In the other common
> case of an ipv6 nexthop then 16 bytes more than required are
> used. With large numbers of MPLS routes this extra memory usage could
> start to become significant.
>
> To avoid allocating memory for a maximum length via address when not
> all of it is required and to allow for ease of iterating over
> nexthops, then the via addresses are changed to be stored in the same
> memory block as the route and nexthops, but in an array after the end
> of the array of nexthops. New accessors are provided to retrieve a
> pointer to the via address.
>
> To allow for O(1) access without having to store a pointer or offset
> per nh, the via address for each nexthop is sized according to the
> maximum via address for any nexthop in the route, which is stored in a
> new route field, rt_max_alen, but this is in an existing hole in
> struct mpls_route so it doesn't increase the size of the
> structure. Each via address is ensured to be aligned to VIA_ALEN_ALIGN
> to account for architectures that don't allow unaligned accesses.
>
> Signed-off-by: Robert Shearman <rshearma@brocade.com>
> ---
nice way to handle it!. I was going to submit a patch to make MAX_VIA_ALEN = 16bytes as suggested by Eric.
In which case, your patch will only help the case where all nexthops are ipv4.
next prev parent reply other threads:[~2015-10-28 1:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-27 0:37 [PATCH net-next 0/2] mpls: mulipath improvements Robert Shearman
2015-10-27 0:37 ` [PATCH net-next 1/2] mpls: fix forwarding using v4/v6 explicit null Robert Shearman
2015-10-28 1:22 ` roopa
2015-10-27 0:37 ` [PATCH net-next 2/2] mpls: reduce memory usage of routes Robert Shearman
2015-10-28 1:39 ` roopa [this message]
2015-10-28 2:53 ` [PATCH net-next 0/2] mpls: mulipath improvements David Miller
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=56302748.7050209@cumulusnetworks.com \
--to=roopa@cumulusnetworks.com \
--cc=davem@davemloft.net \
--cc=ebiederm@xmission.com \
--cc=netdev@vger.kernel.org \
--cc=rshearma@brocade.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.