On Tue, May 14, 2013 at 12:01 AM, Ben Hutchings
<bhutchings@xxxxxxxxxxxxxx> wrote:
> efx_start_datapath() asserts that we can fit 2 RX scatter buffers plus
> a software structure, each appropriately aligned, into a single page.
> Where L1_CACHE_BYTES == 256 and PAGE_SIZE == 4096, which is the case
> on s390, this assertion fails.
>
> The current scatter buffer size is also not a multiple of 64 or 128,
> which are more common cache line sizes. If we can make both the start
> and end of a scatter buffer cache-aligned, this will reduce the need
> for read-modify-write operations on inter- processor links.
>
> Fix the alignment by reducing EFX_RX_USR_BUF_SIZE to 2048 - 256 ==
> 1792. (We could use 2048 - L1_CACHE_BYTES, but EFX_RX_USR_BUF_SIZE
> also affects user-level networking where a larger amount of
> housekeeping data may be needed. Although this version of the driver
> does not support user-level networking, I prefer to keep scattering
> behaviour consistent with the out-of-tree version.)
>
> This still doesn't fix the s390 build because like most architectures
> it has NET_IP_ALIGN == 2. When NET_IP_ALIGN != 0 we cannot achieve
> cache line alignment at either the start or end of a scatter buffer,
> so there is actually no point in padding the buffers to a multiple of
> the cache line size. All we need is 4-byte alignment of the network
> header, so do that.
>
> Adjust the assertions accordingly.
>
> Reported-by: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
> Reported-by: Heiko Carstens <heiko.carstens@xxxxxxxxxx>
> Signed-off-by: Ben Hutchings <bhutchings@xxxxxxxxxxxxxx>
Fixes the s390 build, so
Acked-by: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-s390" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
