All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steffen Klassert <steffen.klassert@secunet.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: xfrm4_state_afinfo size increase (was: Re: xfrm: Add a xfrm type offload.)
Date: Thu, 4 May 2017 11:16:40 +0200	[thread overview]
Message-ID: <20170504091640.GR2649@secunet.com> (raw)
In-Reply-To: <CAMuHMdW=qBz+0qaXRRdBc=jKBA9aGqKafrQQ8rUiQhKv2UmW_Q@mail.gmail.com>

On Thu, May 04, 2017 at 10:08:07AM +0200, Geert Uytterhoeven wrote:
> > @@ -314,12 +316,14 @@ void km_state_expired(struct xfrm_state *x, int hard, u32 portid);
> >  int __xfrm_state_delete(struct xfrm_state *x);
> >
> >  struct xfrm_state_afinfo {
> > -       unsigned int            family;
> > -       unsigned int            proto;
> > -       __be16                  eth_proto;
> > -       struct module           *owner;
> > -       const struct xfrm_type  *type_map[IPPROTO_MAX];
> > -       struct xfrm_mode        *mode_map[XFRM_MODE_MAX];
> > +       unsigned int                    family;
> > +       unsigned int                    proto;
> > +       __be16                          eth_proto;
> > +       struct module                   *owner;
> > +       const struct xfrm_type          *type_map[IPPROTO_MAX];
> > +       const struct xfrm_type_offload  *type_offload_map[IPPROTO_MAX];
> > +       struct xfrm_mode                *mode_map[XFRM_MODE_MAX];
> 
> Bloat-o-meter reports the addition of xfrm_state_afinfo.type_offload_map[]
> increases the static kernel size by 1 KiB on 32-bit platforms (double on 64-bit
> platforms):
> 
> function                                     old     new   delta
>     xfrm4_state_afinfo                          1102    2126   +1024
> 
> While IPPROTO_MAX = 256, the defined list of IP protocols is spread
> sparsely over the number space, but I assume all values may occur?

Actually no, I think we could boil this down to less than ten
really used protocols by mapping the IPPROTO numbers to some
XFRMPROTO numbers.

I'll look into this.

Thanks!

      reply	other threads:[~2017-05-04  9:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-04  8:08 xfrm4_state_afinfo size increase (was: Re: xfrm: Add a xfrm type offload.) Geert Uytterhoeven
2017-05-04  8:08 ` Geert Uytterhoeven
2017-05-04  9:16 ` Steffen Klassert [this message]

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=20170504091640.GR2649@secunet.com \
    --to=steffen.klassert@secunet.com \
    --cc=davem@davemloft.net \
    --cc=geert@linux-m68k.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --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 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.