[PATCH] introduce HAVE_EFFICIENT_UNALIGNED_ACCESS Kconfig symbol - Kernel

This is a discussion on [PATCH] introduce HAVE_EFFICIENT_UNALIGNED_ACCESS Kconfig symbol - Kernel ; In many cases, especially in networking, it can be beneficial to know at compile time whether the architecture can do unaligned accesses efficiently. This patch introduces a new Kconfig symbol HAVE_EFFICIENT_UNALIGNED_ACCESS for that purpose and adds it to the powerpc ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: [PATCH] introduce HAVE_EFFICIENT_UNALIGNED_ACCESS Kconfig symbol

  1. [PATCH] introduce HAVE_EFFICIENT_UNALIGNED_ACCESS Kconfig symbol

    In many cases, especially in networking, it can be beneficial to
    know at compile time whether the architecture can do unaligned
    accesses efficiently. This patch introduces a new Kconfig symbol
    HAVE_EFFICIENT_UNALIGNED_ACCESS
    for that purpose and adds it to the powerpc and x86 architectures.
    Also add some documentation about alignment and networking, and
    especially one intended use of this symbol.

    Signed-off-by: Johannes Berg
    Acked-by: Sam Ravnborg
    Acked-by: Ingo Molnar [x86 architecture part]
    ---
    v5: rename to HAVE_EFFICIENT_UNALIGNED_ACCESS

    I have opted to not introduce any symbol associated with the cost
    of unaligned accesses, David Woodhouse once suggested that such a
    cost should be combined with a probability of (un-)alignment even
    in the get_unaligned/put_unaligned macros and I think this should
    be combined with a patch introducing a global cost constant.

    Also, this would require architecture changes because if some code
    knew the likelyhood of unaligned accesses was small enough over
    the cost of them, architectures that complain in the trap handle
    would still complain in that unlikely case although the code
    explicitly made a trade-off based on the cost/probability.

    Documentation/unaligned-memory-access.txt | 32 +++++++++++++++++++++++++++---
    arch/Kconfig | 19 +++++++++++++++++
    arch/powerpc/Kconfig | 1
    arch/x86/Kconfig | 1
    4 files changed, 50 insertions(+), 3 deletions(-)

    --- everything.orig/Documentation/unaligned-memory-access.txt 2008-04-04 23:42:50.000000000 +0200
    +++ everything/Documentation/unaligned-memory-access.txt 2008-04-04 23:52:15.000000000 +0200
    @@ -218,9 +218,35 @@ If use of such macros is not convenient,
    where the source or destination (or both) are of type u8* or unsigned char*.
    Due to the byte-wise nature of this operation, unaligned accesses are avoided.

    +
    +Alignment vs. Networking
    +========================
    +
    +On architectures that require aligned loads, networking requires that the IP
    +header is aligned on a four-byte boundary to optimise the IP stack. For
    +regular ethernet hardware, the constant NET_IP_ALIGN is used, on most
    +architectures this constant has the value 2 because the normal ethernet
    +header is 14 bytes long, so in order to get proper alignment one needs to
    +DMA to an address that is can be expressed as 4*n + 2. One notable exception
    +here is powerpc which defines NET_IP_ALIGN to 0 because DMA to unaligned
    +addresses can be very expensive and dwarf the cost of unaligned loads.
    +
    +For some ethernet hardware that cannot DMA to unaligned addresses like
    +4*n+2 or non-ethernet hardware, this can be a problem, and it is then
    +required to copy the incoming frame into an aligned buffer. Because this is
    +unnecessary on architectures that can do unaligned accesses, the code can be
    +made depend on CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS like so:
    +
    +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
    + skb = original skb
    +#else
    + skb = copy skb
    +#endif
    +
    --
    -Author: Daniel Drake
    +Authors: Daniel Drake ,
    + Johannes Berg
    With help from: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt,
    -Johannes Berg, Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Han****,
    -Uli Kunitz, Vadim Lobanov
    +Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Han****, Uli Kunitz,
    +Vadim Lobanov

    --- everything.orig/arch/powerpc/Kconfig 2008-04-04 23:42:53.000000000 +0200
    +++ everything/arch/powerpc/Kconfig 2008-04-04 23:52:15.000000000 +0200
    @@ -103,6 +103,7 @@ config PPC
    select HAVE_OPROFILE
    select HAVE_KPROBES
    select HAVE_KRETPROBES
    + select HAVE_EFFICIENT_UNALIGNED_ACCESS

    config EARLY_PRINTK
    bool
    --- everything.orig/arch/x86/Kconfig 2008-04-04 23:42:50.000000000 +0200
    +++ everything/arch/x86/Kconfig 2008-04-04 23:52:15.000000000 +0200
    @@ -23,6 +23,7 @@ config X86
    select HAVE_KPROBES
    select HAVE_KRETPROBES
    select HAVE_KVM if ((X86_32 && !X86_VOYAGER && !X86_VISWS && !X86_NUMAQ) || X86_64)
    + select HAVE_EFFICIENT_UNALIGNED_ACCESS


    config GENERIC_LOCKBREAK
    --- everything.orig/arch/Kconfig 2008-04-04 23:42:50.000000000 +0200
    +++ everything/arch/Kconfig 2008-04-04 23:52:15.000000000 +0200
    @@ -36,3 +36,22 @@ config HAVE_KPROBES

    config HAVE_KRETPROBES
    def_bool n
    +
    +config HAVE_EFFICIENT_UNALIGNED_ACCESS
    + def_bool n
    + help
    + Some architectures are unable to perform unaligned accesses
    + without the use of get_unaligned/put_unaligned. Others are
    + unable to perform such accesses efficiently (e.g. trap on
    + unaligned access and require fixing it up in the exception
    + handler.)
    +
    + This symbol should be selected by an architecture if it can
    + perform unaligned accesses efficiently to allow different
    + code paths to be selected for these cases. Some network
    + drivers, for example, could opt to not fix up alignment
    + problems with received packets if doing so would not help
    + much.
    +
    + See Documentation/unaligned-memory-access.txt for more
    + information on the topic of unaligned memory accesses.


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH] introduce HAVE_EFFICIENT_UNALIGNED_ACCESS Kconfig symbol

    Johannes Berg wrote:
    > --- everything.orig/Documentation/unaligned-memory-access.txt 2008-04-04 23:42:50.000000000 +0200
    > +++ everything/Documentation/unaligned-memory-access.txt 2008-04-04 23:52:15.000000000 +0200
    > @@ -218,9 +218,35 @@ If use of such macros is not convenient,
    > where the source or destination (or both) are of type u8* or unsigned char*.
    > Due to the byte-wise nature of this operation, unaligned accesses are avoided.
    >
    > +
    > +Alignment vs. Networking
    > +========================
    > +
    > +On architectures that require aligned loads, networking requires that the IP
    > +header is aligned on a four-byte boundary to optimise the IP stack. For
    > +regular ethernet hardware, the constant NET_IP_ALIGN is used, on most


    . On

    > +architectures this constant has the value 2 because the normal ethernet
    > +header is 14 bytes long, so in order to get proper alignment one needs to


    . So

    > +DMA to an address that is can be expressed as 4*n + 2. One notable exception


    which can

    > +here is powerpc which defines NET_IP_ALIGN to 0 because DMA to unaligned
    > +addresses can be very expensive and dwarf the cost of unaligned loads.
    > +
    > +For some ethernet hardware that cannot DMA to unaligned addresses like
    > +4*n+2 or non-ethernet hardware, this can be a problem, and it is then
    > +required to copy the incoming frame into an aligned buffer. Because this is
    > +unnecessary on architectures that can do unaligned accesses, the code can be
    > +made depend on CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS like so:


    made dependent on

    > +
    > +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
    > + skb = original skb
    > +#else
    > + skb = copy skb
    > +#endif
    > +
    > --
    > -Author: Daniel Drake
    > +Authors: Daniel Drake ,
    > + Johannes Berg
    > With help from: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt,
    > -Johannes Berg, Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Han****,
    > -Uli Kunitz, Vadim Lobanov
    > +Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Han****, Uli Kunitz,
    > +Vadim Lobanov
    >
    > --- everything.orig/arch/powerpc/Kconfig 2008-04-04 23:42:53.000000000 +0200
    > +++ everything/arch/powerpc/Kconfig 2008-04-04 23:52:15.000000000 +0200
    > @@ -103,6 +103,7 @@ config PPC
    > select HAVE_OPROFILE
    > select HAVE_KPROBES
    > select HAVE_KRETPROBES
    > + select HAVE_EFFICIENT_UNALIGNED_ACCESS
    >
    > config EARLY_PRINTK
    > bool
    > --- everything.orig/arch/x86/Kconfig 2008-04-04 23:42:50.000000000 +0200
    > +++ everything/arch/x86/Kconfig 2008-04-04 23:52:15.000000000 +0200
    > @@ -23,6 +23,7 @@ config X86
    > select HAVE_KPROBES
    > select HAVE_KRETPROBES
    > select HAVE_KVM if ((X86_32 && !X86_VOYAGER && !X86_VISWS && !X86_NUMAQ) || X86_64)
    > + select HAVE_EFFICIENT_UNALIGNED_ACCESS
    >
    >
    > config GENERIC_LOCKBREAK
    > --- everything.orig/arch/Kconfig 2008-04-04 23:42:50.000000000 +0200
    > +++ everything/arch/Kconfig 2008-04-04 23:52:15.000000000 +0200
    > @@ -36,3 +36,22 @@ config HAVE_KPROBES
    >
    > config HAVE_KRETPROBES
    > def_bool n
    > +
    > +config HAVE_EFFICIENT_UNALIGNED_ACCESS
    > + def_bool n
    > + help
    > + Some architectures are unable to perform unaligned accesses
    > + without the use of get_unaligned/put_unaligned. Others are
    > + unable to perform such accesses efficiently (e.g. trap on


    Wouldn't a comment be more appropriate instead of a help text? This
    option shouldn't be a visible make XYZconfig prompt.

    I have no comment on the option itself; it's not my domain.
    --
    Stefan Richter
    -=====-==--- -=-- -=---
    http://arcgraph.de/sr/
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH] introduce HAVE_EFFICIENT_UNALIGNED_ACCESS Kconfig symbol

    Stefan,

    Thanks for the text review. I'll follow up with a new version in a
    minute.

    > > --- everything.orig/arch/Kconfig 2008-04-04 23:42:50.000000000 +0200
    > > +++ everything/arch/Kconfig 2008-04-04 23:52:15.000000000 +0200
    > > @@ -36,3 +36,22 @@ config HAVE_KPROBES
    > >
    > > config HAVE_KRETPROBES
    > > def_bool n
    > > +
    > > +config HAVE_EFFICIENT_UNALIGNED_ACCESS
    > > + def_bool n
    > > + help
    > > + Some architectures are unable to perform unaligned accesses
    > > + without the use of get_unaligned/put_unaligned. Others are
    > > + unable to perform such accesses efficiently (e.g. trap on

    >
    > Wouldn't a comment be more appropriate instead of a help text? This
    > option shouldn't be a visible make XYZconfig prompt.
    >
    > I have no comment on the option itself; it's not my domain.


    Note that the help text doesn't mean the option gets to be visible, only
    the one-line description does, as in

    config XYZ
    bool "description"

    vs.
    config XYZ
    bool

    johannes

    -----BEGIN PGP SIGNATURE-----
    Comment: Johannes Berg (powerbook)

    iQIVAwUAR/uWsKVg1VMiehFYAQJ/OA//TC53B8iR2LTTp/HLOShJM/mjaN4fSXq3
    pfgpTIOKGGU7ygCWdXBQlvDBHGafpCKdmxI8MOtsQlozGm/YTRoe+uDqCH8z2CZ6
    7E2XSeGY6lII5rZDidtO46jGIkuFvwgjUQDL87zOJOPPe4O8nU rVBKdbym2jOHnG
    BlckWS0waU6QR+WPH8LayUCrIGxloT8csFHHCKjwfU4M5X2ctj UfxCrR7cexrrFl
    WlCDhxWAaGhIMMxolWmQJy11Gt+oNbTOkxwDaeVQwArsL56pNd eNLb5k112xL+6t
    6ukIqHxLLcNgcAV8QYafhRzMP1yHgoZlyRVfBf2XZUB98NIw8q imN5pKMeA6mXVY
    OfccqE+ivOmGf/diT+8nca/whI5YXbx52qzWTOAubPoyYRVP+CHkuasecgH7x2IR
    rjrhPeaLtBVOzKemD6BEIFFFDVIayRvPWK98VV5V98dvY9QDxY jNAbOjYX5mHgTj
    91JPHqKER1BGMrpxcaOrXzygfHNS5sqhjuqNG1lDNztc8MCOBM MYBSEljTT1vRa4
    4MBKRT9dT6U9zpe4MLt84Ev0zuUR2l7FNAtImQTRRvUNS2m+Ah d3eyuBX0yQCi18
    wE81YpmWk56h/PcKIyAiVDgXWwuyvf3cAl/Yyz69HC5GDvBQceWuP2XhcvGYRDTq
    2AYwuJUikcE=
    =1j5g
    -----END PGP SIGNATURE-----


  4. [PATCH v6] introduce HAVE_EFFICIENT_UNALIGNED_ACCESS Kconfig symbol

    In many cases, especially in networking, it can be beneficial to
    know at compile time whether the architecture can do unaligned
    accesses efficiently. This patch introduces a new Kconfig symbol
    HAVE_EFFICIENT_UNALIGNED_ACCESS
    for that purpose and adds it to the powerpc and x86 architectures.
    Also add some documentation about alignment and networking, and
    especially one intended use of this symbol.

    Signed-off-by: Johannes Berg
    Acked-by: Sam Ravnborg
    Acked-by: Ingo Molnar [x86 architecture part]
    ---
    v5: rename to HAVE_EFFICIENT_UNALIGNED_ACCESS
    v6: small text fixes

    I have opted to not introduce any symbol associated with the cost
    of unaligned accesses, David Woodhouse once suggested that such a
    cost should be combined with a probability of (un-)alignment even
    in the get_unaligned/put_unaligned macros and I think this should
    be combined with a patch introducing a global cost constant.

    Also, this would require architecture changes because if some code
    knew the likelyhood of unaligned accesses was small enough over
    the cost of them, architectures that complain in the trap handle
    would still complain in that unlikely case although the code
    explicitly made a trade-off based on the cost/probability.

    Documentation/unaligned-memory-access.txt | 32 +++++++++++++++++++++++++++---
    arch/Kconfig | 19 +++++++++++++++++
    arch/powerpc/Kconfig | 1
    arch/x86/Kconfig | 1
    4 files changed, 50 insertions(+), 3 deletions(-)

    --- everything.orig/Documentation/unaligned-memory-access.txt 2008-04-08 17:07:07.000000000 +0200
    +++ everything/Documentation/unaligned-memory-access.txt 2008-04-08 18:02:27.000000000 +0200
    @@ -218,9 +218,35 @@ If use of such macros is not convenient,
    where the source or destination (or both) are of type u8* or unsigned char*.
    Due to the byte-wise nature of this operation, unaligned accesses are avoided.

    +
    +Alignment vs. Networking
    +========================
    +
    +On architectures that require aligned loads, networking requires that the IP
    +header is aligned on a four-byte boundary to optimise the IP stack. For
    +regular ethernet hardware, the constant NET_IP_ALIGN is used. On most
    +architectures this constant has the value 2 because the normal ethernet
    +header is 14 bytes long, so in order to get proper alignment one needs to
    +DMA to an address which can be expressed as 4*n + 2. One notable exception
    +here is powerpc which defines NET_IP_ALIGN to 0 because DMA to unaligned
    +addresses can be very expensive and dwarf the cost of unaligned loads.
    +
    +For some ethernet hardware that cannot DMA to unaligned addresses like
    +4*n+2 or non-ethernet hardware, this can be a problem, and it is then
    +required to copy the incoming frame into an aligned buffer. Because this is
    +unnecessary on architectures that can do unaligned accesses, the code can be
    +made dependent on CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS like so:
    +
    +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
    + skb = original skb
    +#else
    + skb = copy skb
    +#endif
    +
    --
    -Author: Daniel Drake
    +Authors: Daniel Drake ,
    + Johannes Berg
    With help from: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt,
    -Johannes Berg, Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Han****,
    -Uli Kunitz, Vadim Lobanov
    +Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Han****, Uli Kunitz,
    +Vadim Lobanov

    --- everything.orig/arch/powerpc/Kconfig 2008-04-08 17:09:41.000000000 +0200
    +++ everything/arch/powerpc/Kconfig 2008-04-08 17:09:42.000000000 +0200
    @@ -103,6 +103,7 @@ config PPC
    select HAVE_OPROFILE
    select HAVE_KPROBES
    select HAVE_KRETPROBES
    + select HAVE_EFFICIENT_UNALIGNED_ACCESS

    config EARLY_PRINTK
    bool
    --- everything.orig/arch/x86/Kconfig 2008-04-08 17:07:07.000000000 +0200
    +++ everything/arch/x86/Kconfig 2008-04-08 17:09:42.000000000 +0200
    @@ -23,6 +23,7 @@ config X86
    select HAVE_KPROBES
    select HAVE_KRETPROBES
    select HAVE_KVM if ((X86_32 && !X86_VOYAGER && !X86_VISWS && !X86_NUMAQ) || X86_64)
    + select HAVE_EFFICIENT_UNALIGNED_ACCESS


    config GENERIC_LOCKBREAK
    --- everything.orig/arch/Kconfig 2008-04-08 17:07:07.000000000 +0200
    +++ everything/arch/Kconfig 2008-04-08 17:09:42.000000000 +0200
    @@ -36,3 +36,22 @@ config HAVE_KPROBES

    config HAVE_KRETPROBES
    def_bool n
    +
    +config HAVE_EFFICIENT_UNALIGNED_ACCESS
    + def_bool n
    + help
    + Some architectures are unable to perform unaligned accesses
    + without the use of get_unaligned/put_unaligned. Others are
    + unable to perform such accesses efficiently (e.g. trap on
    + unaligned access and require fixing it up in the exception
    + handler.)
    +
    + This symbol should be selected by an architecture if it can
    + perform unaligned accesses efficiently to allow different
    + code paths to be selected for these cases. Some network
    + drivers, for example, could opt to not fix up alignment
    + problems with received packets if doing so would not help
    + much.
    +
    + See Documentation/unaligned-memory-access.txt for more
    + information on the topic of unaligned memory accesses.


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [PATCH] introduce HAVE_EFFICIENT_UNALIGNED_ACCESS Kconfig symbol

    Hi,

    On Tuesday 8. April 2008, Johannes Berg wrote:

    > In many cases, especially in networking, it can be beneficial to
    > know at compile time whether the architecture can do unaligned
    > accesses efficiently. This patch introduces a new Kconfig symbol
    > HAVE_EFFICIENT_UNALIGNED_ACCESS
    > for that purpose and adds it to the powerpc and x86 architectures.
    > Also add some documentation about alignment and networking, and
    > especially one intended use of this symbol.


    Please CC linux-arch@vger.kernel.org for such changes, so it's more likely
    noticed by more arch maintainers, so a list can be compiled what is
    appropriate for the various archs.
    The scope of this symbol is IMO a little unclear, is it intended for one-time
    accesses to small object or also for repeated accesses to larger objects?
    Anyway, this probably should be set for m68k as well.

    bye, Roman
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [PATCH] introduce HAVE_EFFICIENT_UNALIGNED_ACCESS Kconfig symbol

    Hi,

    > Please CC linux-arch@vger.kernel.org for such changes, so it's more likely
    > noticed by more arch maintainers, so a list can be compiled what is
    > appropriate for the various archs.


    Hah. I thought there was such a list but it didn't show up in
    MAINTAINERS so I thought I was wrong.

    > The scope of this symbol is IMO a little unclear, is it intended for one-time
    > accesses to small object or also for repeated accesses to larger objects?
    > Anyway, this probably should be set for m68k as well.


    Also for repeated accesses, for example network packets where the IPv4
    header might not always be aligned. That's why we want it to be
    "efficient", not just "possible" (as an earlier version of the patch
    called it.)

    johannes

    -----BEGIN PGP SIGNATURE-----
    Comment: Johannes Berg (powerbook)

    iQIVAwUAR/zIDqVg1VMiehFYAQLspQ/9GCcNILMzg6k5U/LsudZTw41Q0jLcDrcV
    IP7njVlTNPg5PTOzMzMkDuj/uCDTAE9WDEIjgeHQqGWyBak8Qhs5YqfW41FbbFkJ
    0ln+G2trSQNN/mt6S7eWE00y1ftavS8LXUkO7Sar/pupzFbODI6DeMVnUf//ZAFt
    pUrU9BnTa7yoPi3lD3okLxQBK0cvwkr7q9/sNdhGnN2grdS5GVKUCEI0zFtARC9b
    HBY2AP6daVHbs3uo0zLc+Sax76gwMa3xxrql/Rx5FRTPQfcqFsfNJC+Ox05TjT1R
    AMJ2uo4XrfsVvrBkaJL9Yux0NjNUH0G6OCvq8LGwCcWdQpFEbv hGtOw5d7reZJfB
    Ak+B5Y7tF1qz2PUDMtk389Pz5QtPpN/T+54cHhRWlCklKr1stHUHF3yk49B+IYRf
    +uIwhO6ClKQdNio4my8MzeLGJKgLjndpdZ0hKAZkalyFKANlm8 RqigRciA5gbGcc
    E1dpY94D7pDu3qPf6LevU3T/dKfUr0IDL4JNdmiBEteGoUQSKYpEkDFP/xvoETDi
    WGqctvV2h2audL+q245FpaV44hKLm++e9spdnGniWC0lwLEtQ3 7/hr/VNKeRtJJ+
    sXRzcYrWHPZkX4bLRvrS2BZizw6x+6/AD9Rr6rHEH/jRwtrOPvmxtigbPy5MxzY1
    eGZ+g4+bz/Q=
    =1ksc
    -----END PGP SIGNATURE-----


+ Reply to Thread