linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Edward Cree <ecree@solarflare.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>,
	Alexander Lobakin <alobakin@dlink.ru>
Cc: "David S. Miller" <davem@davemloft.net>,
	Jiri Pirko <jiri@mellanox.com>,
	Eric Dumazet <edumazet@google.com>,
	Ido Schimmel <idosch@mellanox.com>,
	"Paolo Abeni" <pabeni@redhat.com>,
	Petr Machata <petrm@mellanox.com>,
	Sabrina Dubroca <sd@queasysnail.net>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Jassi Brar <jaswinder.singh@linaro.org>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 net-next] net: core: use listified Rx for GRO_NORMAL in napi_gro_receive()
Date: Thu, 25 Jun 2020 15:25:38 +0100	[thread overview]
Message-ID: <948c5844-b8e4-81d3-b5eb-b13b1d3cda38@solarflare.com> (raw)
In-Reply-To: <20200624210606.GA1362687@zx2c4.com>

On 24/06/2020 22:06, Jason A. Donenfeld wrote:
> Hi Alexander,
>
> This patch introduced a behavior change around GRO_DROP:
>
> napi_skb_finish used to sometimes return GRO_DROP:
>
>> -static gro_result_t napi_skb_finish(gro_result_t ret, struct sk_buff *skb)
>> +static gro_result_t napi_skb_finish(struct napi_struct *napi,
>> +				    struct sk_buff *skb,
>> +				    gro_result_t ret)
>>  {
>>  	switch (ret) {
>>  	case GRO_NORMAL:
>> -		if (netif_receive_skb_internal(skb))
>> -			ret = GRO_DROP;
>> +		gro_normal_one(napi, skb);
>>
> But under your change, gro_normal_one and the various calls that makes
> never propagates its return value, and so GRO_DROP is never returned to
> the caller, even if something drops it.
This followed the pattern set by napi_frags_finish(), and is
 intentional: gro_normal_one() usually defers processing of
 the skb to the end of the napi poll, so by the time we know
 that the network stack has dropped it, the caller has long
 since returned.
In fact the RX will be handled by netif_receive_skb_list_internal(),
 which can't return NET_RX_SUCCESS vs. NET_RX_DROP, because it's
 handling many skbs which might not all have the same verdict.

When originally doing this work I felt this was OK because
 almost no-one was sensitive to the return value — almost the
 only callers that were were in our own sfc driver, and then
 only for making bogus decisions about interrupt moderation.
Alexander just followed my lead, so don't blame him ;-)

> For some context, I'm consequently mulling over this change in my code,
> since checking for GRO_DROP now constitutes dead code:
Incidentally, it's only dead because dev_gro_receive() can't
 return GRO_DROP either.  If it could, napi_skb_finish()
 would pass that on.  And napi_gro_frags() (which AIUI is the
 better API for some performance reasons that I can't remember)
 can still return GRO_DROP too.

However, I think that incrementing your rx_dropped stat when
 the network stack chose to drop the packet is the wrong
 thing to do anyway (IMHO rx_dropped is for "there was a
 packet on the wire but either the hardware or the driver was
 unable to receive it"), so I'd say go ahead and remove the
 check.

HTH
-ed

      parent reply	other threads:[~2020-06-25 14:25 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-14  8:00 [PATCH v2 net-next] net: core: use listified Rx for GRO_NORMAL in napi_gro_receive() Alexander Lobakin
2019-10-16  1:16 ` David Miller
2019-10-16  7:31   ` Alexander Lobakin
2019-11-25  7:29     ` Nicholas Johnson
2019-11-25  7:54       ` Alexander Lobakin
2019-11-25  8:25         ` Alexander Lobakin
2019-11-25  9:09           ` Nicholas Johnson
2019-11-25 10:31             ` Edward Cree
2019-11-25 10:58               ` Alexander Lobakin
2019-11-25 11:05                 ` Johannes Berg
2019-11-25 11:42                   ` Paolo Abeni
2019-11-25 12:02                     ` Alexander Lobakin
2019-11-25 13:21                       ` Edward Cree
2019-11-25 13:39                         ` Alexander Lobakin
2019-11-26 23:57                       ` David Miller
2019-11-27  7:47                         ` Alexander Lobakin
2019-11-27  8:30                           ` Johannes Berg
2019-11-27  9:47                         ` Alexander Lobakin
2019-11-25 12:11                     ` Kalle Valo
2019-11-25 13:07                     ` Nicholas Johnson
2019-11-25 13:11               ` Nicholas Johnson
2020-06-24 21:06 ` Jason A. Donenfeld
2020-06-24 21:28   ` Jason A. Donenfeld
2020-06-25 14:25   ` Edward Cree [this message]

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=948c5844-b8e4-81d3-b5eb-b13b1d3cda38@solarflare.com \
    --to=ecree@solarflare.com \
    --cc=Jason@zx2c4.com \
    --cc=alobakin@dlink.ru \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=idosch@mellanox.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=jaswinder.singh@linaro.org \
    --cc=jiri@mellanox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=petrm@mellanox.com \
    --cc=sd@queasysnail.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).