netdev - Re: [PATCH net-next 3/9] sfc: Increase size of RX SKB header area

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1373997228.2120.15.camel@bwh-desktop.uk.level5networks.com>
Date:	Tue, 16 Jul 2013 18:53:48 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	David Miller <davem@...emloft.net>, <netdev@...r.kernel.org>,
	<linux-net-drivers@...arflare.com>
Subject: Re: [PATCH net-next 3/9] sfc: Increase size of RX SKB header area

On Tue, 2013-07-16 at 10:33 -0700, Eric Dumazet wrote:
> On Mon, 2013-06-24 at 21:13 +0100, Ben Hutchings wrote:
> > From: Jon Cooper <jcooper@...arflare.com>
> > 
> > This allows the SKB to hold the headers without reallocation more often.
> > 
> > Signed-off-by: Ben Hutchings <bhutchings@...arflare.com>
> > ---
> >  drivers/net/ethernet/sfc/rx.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/ethernet/sfc/rx.c b/drivers/net/ethernet/sfc/rx.c
> > index b915e09..6efff3d 100644
> > --- a/drivers/net/ethernet/sfc/rx.c
> > +++ b/drivers/net/ethernet/sfc/rx.c
> > @@ -36,7 +36,7 @@
> >  #define EFX_RECYCLE_RING_SIZE_NOIOMMU (2 * EFX_RX_PREFERRED_BATCH)
> >  
> >  /* Size of buffer allocated for skb header area. */
> > -#define EFX_SKB_HEADERS  64u
> > +#define EFX_SKB_HEADERS  128u
> >  
> >  /* This is the percentage fill level below which new RX descriptors
> >   * will be added to the RX descriptor ring.
> > 
> 
> This patch brings performance decrease for tunnels, because it pulls
> into skb->head 128 bytes worth of data.
>
> This includes TCP payload, so GRO or TCP coalescing code is less
> effective. Each MSS spans 2 memory areas (small part on skb->head,
> remaining on the fragment) : GRO packets have only 8 MSS worth of data,
> instead of 16.
> 
> The fix would be to allocate 128 bytes in skb->head to prevent future
> reallocations of skb->head, but pull 64 bytes only.

Perhaps, yes.  I also thought of using some of the other parser status
from RX completions to estimate the length of headers.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
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