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

From: Jon Cooper <jcooper@solarflare.com>

This allows the SKB to hold the headers without reallocation more often.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
 drivers/net/ethernet/sfc/rx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On Mon, 2013-06-24 at 21:13 +0100, Ben Hutchings wrote:
> From: Jon Cooper <jcooper@solarflare.com>
> 
> This allows the SKB to hold the headers without reallocation more often.
> 
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.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.



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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@solarflare.com>
> > 
> > This allows the SKB to hold the headers without reallocation more often.
> > 
> > Signed-off-by: Ben Hutchings <bhutchings@solarflare.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.

On Tue, 2013-07-16 at 18:53 +0100, Ben Hutchings wrote:

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

That would be ideal indeed, I can provide a patch.


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html