netdev - Re: MAX_SKB_FRAGS and GRO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100208124704.GA8538@gondor.apana.org.au>
Date:	Mon, 8 Feb 2010 23:47:04 +1100
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Anton Blanchard <anton@...ba.org>
Cc:	Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
	Jesse Brandeburg <jesse.brandeburg@...el.com>,
	Bruce Allan <bruce.w.allan@...el.com>,
	Alex Duyck <alexander.h.duyck@...el.com>,
	PJ Waskiewicz <peter.p.waskiewicz.jr@...el.com>,
	John Ronciak <john.ronciak@...el.com>, divy@...lsio.com,
	netdev@...r.kernel.org
Subject: Re: MAX_SKB_FRAGS and GRO

On Mon, Feb 08, 2010 at 09:03:07PM +1100, Anton Blanchard wrote:
> 
> I was looking through the hardware GRO support in various drivers and I think
> we have a couple of issues with PAGE_SIZE > 4k. For example, if we have a 64kB
> page size then MAX_SKB_FRAGS ends up as 3:
> 
> #define MAX_SKB_FRAGS (65536/PAGE_SIZE + 2)
> 
> This should be fine for hardware and software GSO, but we encounter issues
> with hardware GRO (not sure about software GRO).
> 
> In the ixgbe case we use MAX_SKB_FRAGS to program the max number of GRO
> descriptors, even though we assemble GRO packets using ->frag_list:
> 
> #if (MAX_SKB_FRAGS > 16)
>                 rscctrl |= IXGBE_RSCCTL_MAXDESC_16;
> #elif (MAX_SKB_FRAGS > 8)
>                 rscctrl |= IXGBE_RSCCTL_MAXDESC_8;
> #elif (MAX_SKB_FRAGS > 4)
>                 rscctrl |= IXGBE_RSCCTL_MAXDESC_4;
> #else
>                 rscctrl |= IXGBE_RSCCTL_MAXDESC_1;
> #endif

First of all this isn't GRO, but RSC.  With GRO we impose extra
restrictions on what packets can be merged while RSC is more
permissive.

In fact I think the ixgbe code may be broken as it is since it's
not marking RSC packets in any way to prevent them from being
forwarded through another interface.

As to your problem with RSC on a 64K page system, I'm sure one
of the Intel developers would be able to help you out.
 
> Thinking out aloud, would setting a pessimistic value for MAX_SKB_FRAGS
> be one way to fix this? ie:
> 
> #define MAX_SKB_FRAGS (65536/4096 + 2)

While I can't think of any serious issues with this, as this is
an entirely ixgbe-specific problem, the fix should probably stay
there.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html