All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: "Ramsay, Lincoln" <Lincoln.Ramsay@digi.com>
Cc: Florian Westphal <fw@strlen.de>,
	Igor Russkikh <irusskikh@marvell.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Dmitry Bogdanov <dbogdanov@marvell.com>
Subject: Re: [PATCH v3] aquantia: Remove the build_skb path
Date: Thu, 19 Nov 2020 23:58:42 +0100	[thread overview]
Message-ID: <20201119225842.GK15137@breakpoint.cc> (raw)
In-Reply-To: <CY4PR1001MB231116E9371FBA2B8636C23DE8E00@CY4PR1001MB2311.namprd10.prod.outlook.com>

Ramsay, Lincoln <Lincoln.Ramsay@digi.com> wrote:
> When performing IPv6 forwarding, there is an expectation that SKBs
> will have some headroom. When forwarding a packet from the aquantia
> driver, this does not always happen, triggering a kernel warning.
> 
> The build_skb path fails to allow for an SKB header, but the hardware

For build_skb path to work the buffer scheme would need to be changed
to reserve headroom, so yes, I think that the proposed patch is the
most convenient solution.

> buffer it is built around won't allow for this anyway. Just always use the
> slower codepath that copies memory into an allocated SKB.

I thought this changes the driver to always copy the entire packet, but
thats not true, see below.

> It seems that skb_headroom is only 14, when it is expected to be >= 16.

Yes, kernel expects to have some headroom in skbs.

> aq_ring.c has this code (edited slightly for brevity):
> 
> if (buff->is_eop && buff->len <= AQ_CFG_RX_FRAME_MAX - AQ_SKB_ALIGN) {
>     skb = build_skb(aq_buf_vaddr(&buff->rxdata), AQ_CFG_RX_FRAME_MAX);
>     skb_put(skb, buff->len);
> } else {
>     skb = napi_alloc_skb(napi, AQ_CFG_RX_HDR_SIZE);
> 
> There is a significant difference between the SKB produced by these 2 code paths. When napi_alloc_skb creates an SKB, there is a certain amount of headroom reserved. The same pattern appears to be used in all of the other ethernet drivers I have looked at. However, this is not done in the build_skb codepath.

I think the above should be part of the commit message rather than this
meta-space (which gets removed by git-am).

> +		skb = napi_alloc_skb(napi, AQ_CFG_RX_HDR_SIZE);
> +		if (unlikely(!skb)) {

AQ_CFG_RX_HDR_SIZE is 256 byte, so for larger packets ...

> +		memcpy(__skb_put(skb, hdr_len), aq_buf_vaddr(&buff->rxdata),
> +			ALIGN(hdr_len, sizeof(long)));

This only copies the initial part and then...
> +		if (buff->len - hdr_len > 0) {
> +			skb_add_rx_frag(skb, 0, buff->rxdata.page,
> +					buff->rxdata.pg_off + hdr_len,
> +					buff->len - hdr_len,
>  					AQ_CFG_RX_FRAME_MAX);

The rest is added as a frag.

IOW, this patch looks good to me, but could you update the
commit message so it becomes clear that this doesn't result in a full
copy?

Perhaps something like:
'Just always use the napi_alloc_skb() code path that passes the buffer
 as a page fragment', or similar.

Thanks.

  parent reply	other threads:[~2020-11-19 22:58 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-18  1:52 [PATCH] aquantia: Reserve space when allocating an SKB Ramsay, Lincoln
2020-11-18 14:02 ` [EXT] " Igor Russkikh
2020-11-19  0:14   ` Ramsay, Lincoln
2020-11-19  5:19     ` Ramsay, Lincoln
2020-11-19 22:01       ` [PATCH] aquantia: Remove the build_skb path Ramsay, Lincoln
2020-11-19 22:07         ` [PATCH v2] " Ramsay, Lincoln
2020-11-19 22:15           ` Florian Westphal
2020-11-19 22:24             ` Ramsay, Lincoln
2020-11-19 22:28               ` Florian Westphal
2020-11-19 22:34                 ` [PATCH v3] " Ramsay, Lincoln
2020-11-19 22:49                   ` Maciej Fijalkowski
2020-11-20  8:18                     ` [EXT] " Igor Russkikh
2020-11-23 19:28                       ` Maciej Fijalkowski
2020-11-24 15:26                         ` Igor Russkikh
2020-11-19 22:58                   ` Florian Westphal [this message]
2020-11-19 23:52                     ` [PATCH v4] " Ramsay, Lincoln
2020-11-20  0:17                       ` Florian Westphal
2020-11-20  0:23                         ` Ramsay, Lincoln
2020-11-21 21:22                       ` Jakub Kicinski
2020-11-21 21:23                         ` Jakub Kicinski
2020-11-22 22:36                           ` Ramsay, Lincoln
2020-11-23 16:42                             ` Jakub Kicinski
2020-11-23 21:40                               ` [PATCH net v5] " Ramsay, Lincoln
2020-11-24 19:02                                 ` Jakub Kicinski
2020-11-22 21:55                         ` [PATCH v4] " Ramsay, Lincoln
2020-11-20  7:52         ` [EXT] [PATCH] " Igor Russkikh
2020-11-23  4:20           ` Ramsay, Lincoln
2020-11-24 14:29             ` Igor Russkikh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201119225842.GK15137@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=Lincoln.Ramsay@digi.com \
    --cc=davem@davemloft.net \
    --cc=dbogdanov@marvell.com \
    --cc=irusskikh@marvell.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.