Re: [PATCH v2 net-next] net: core: use listified Rx for GRO_NORMAL in napi_gro_receive()

[Edward Cree]

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