Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Paul Durrant <xadimgnik@gmail.com>
To: Jan Beulich <jbeulich@suse.com>, Wei Liu <wl@xen.org>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: Ping²: [PATCH] xen-netback: correct success/error reporting for the SKB-with-fraglist case
Date: Thu, 16 Sep 2021 19:34:19 +0100	[thread overview]
Message-ID: <0dff83ff-629a-7179-9fef-77bd1fbf3d09@xen.org> (raw)
In-Reply-To: <d4f381e9-6698-3339-1d17-15e3abc71d06@suse.com>

On 16/09/2021 16:45, Jan Beulich wrote:
> On 15.07.2021 10:58, Jan Beulich wrote:
>> On 20.05.2021 13:46, Jan Beulich wrote:
>>> On 25.02.2021 17:23, Paul Durrant wrote:
>>>> On 25/02/2021 14:00, Jan Beulich wrote:
>>>>> On 25.02.2021 13:11, Paul Durrant wrote:
>>>>>> On 25/02/2021 07:33, Jan Beulich wrote:
>>>>>>> On 24.02.2021 17:39, Paul Durrant wrote:
>>>>>>>> On 23/02/2021 16:29, Jan Beulich wrote:
>>>>>>>>> When re-entering the main loop of xenvif_tx_check_gop() a 2nd time, the
>>>>>>>>> special considerations for the head of the SKB no longer apply. Don't
>>>>>>>>> mistakenly report ERROR to the frontend for the first entry in the list,
>>>>>>>>> even if - from all I can tell - this shouldn't matter much as the overall
>>>>>>>>> transmit will need to be considered failed anyway.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>>>>>>
>>>>>>>>> --- a/drivers/net/xen-netback/netback.c
>>>>>>>>> +++ b/drivers/net/xen-netback/netback.c
>>>>>>>>> @@ -499,7 +499,7 @@ check_frags:
>>>>>>>>>      				 * the header's copy failed, and they are
>>>>>>>>>      				 * sharing a slot, send an error
>>>>>>>>>      				 */
>>>>>>>>> -				if (i == 0 && sharedslot)
>>>>>>>>> +				if (i == 0 && !first_shinfo && sharedslot)
>>>>>>>>>      					xenvif_idx_release(queue, pending_idx,
>>>>>>>>>      							   XEN_NETIF_RSP_ERROR);
>>>>>>>>>      				else
>>>>>>>>>
>>>>>>>>
>>>>>>>> I think this will DTRT, but to my mind it would make more sense to clear
>>>>>>>> 'sharedslot' before the 'goto check_frags' at the bottom of the function.
>>>>>>>
>>>>>>> That was my initial idea as well, but
>>>>>>> - I think it is for a reason that the variable is "const".
>>>>>>> - There is another use of it which would then instead need further
>>>>>>>      amending (and which I believe is at least part of the reason for
>>>>>>>      the variable to be "const").
>>>>>>>
>>>>>>
>>>>>> Oh, yes. But now that I look again, don't you want:
>>>>>>
>>>>>> if (i == 0 && first_shinfo && sharedslot)
>>>>>>
>>>>>> ? (i.e no '!')
>>>>>>
>>>>>> The comment states that the error should be indicated when the first
>>>>>> frag contains the header in the case that the map succeeded but the
>>>>>> prior copy from the same ref failed. This can only possibly be the case
>>>>>> if this is the 'first_shinfo'
>>>>>
>>>>> I don't think so, no - there's a difference between "first frag"
>>>>> (at which point first_shinfo is NULL) and first frag list entry
>>>>> (at which point first_shinfo is non-NULL).
>>>>
>>>> Yes, I realise I got it backwards. Confusing name but the comment above
>>>> its declaration does explain.
>>>>
>>>>>
>>>>>> (which is why I still think it is safe to unconst 'sharedslot' and
>>>>>> clear it).
>>>>>
>>>>> And "no" here as well - this piece of code
>>>>>
>>>>> 		/* First error: if the header haven't shared a slot with the
>>>>> 		 * first frag, release it as well.
>>>>> 		 */
>>>>> 		if (!sharedslot)
>>>>> 			xenvif_idx_release(queue,
>>>>> 					   XENVIF_TX_CB(skb)->pending_idx,
>>>>> 					   XEN_NETIF_RSP_OKAY);
>>>>>
>>>>> specifically requires sharedslot to have the value that was
>>>>> assigned to it at the start of the function (this property
>>>>> doesn't go away when switching from fragments to frag list).
>>>>> Note also how it uses XENVIF_TX_CB(skb)->pending_idx, i.e. the
>>>>> value the local variable pending_idx was set from at the start
>>>>> of the function.
>>>>>
>>>>
>>>> True, we do have to deal with freeing up the header if the first map
>>>> error comes on the frag list.
>>>>
>>>> Reviewed-by: Paul Durrant <paul@xen.org>
>>>
>>> Since I've not seen this go into 5.13-rc, may I ask what the disposition
>>> of this is?
>>
>> I can't seem to spot this in 5.14-rc either. I have to admit I'm
>> increasingly puzzled ...
> 
> Another two months (and another release) later and still nothing. Am
> I doing something wrong? Am I wrongly assuming that maintainers would
> push such changes up the chain?
> 

It has my R-b so it ought to go in via netdev AFAICT.

   Paul


  reply	other threads:[~2021-09-16 19:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-23 16:29 Jan Beulich
2021-02-24 16:39 ` Paul Durrant
2021-02-25  7:33   ` Jan Beulich
2021-02-25 12:11     ` Paul Durrant
2021-02-25 14:00       ` Jan Beulich
2021-02-25 16:23         ` Paul Durrant
2021-05-20 11:46           ` Jan Beulich
2021-07-15  8:58             ` Ping: " Jan Beulich
2021-09-16 15:45               ` Ping²: " Jan Beulich
2021-09-16 18:34                 ` Paul Durrant [this message]
2021-09-16 21:48                   ` Sander Eikelenboom
2021-09-17  6:21                     ` Jan Beulich

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=0dff83ff-629a-7179-9fef-77bd1fbf3d09@xen.org \
    --to=xadimgnik@gmail.com \
    --cc=jbeulich@suse.com \
    --cc=netdev@vger.kernel.org \
    --cc=paul@xen.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    --subject='Re: Ping²: [PATCH] xen-netback: correct success/error reporting for the SKB-with-fraglist case' \
    /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

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