All of lore.kernel.org
 help / color / mirror / Atom feed
From: Saeed Mahameed <saeed@kernel.org>
To: Vadim Fedorenko <vadfed@meta.com>
Cc: Gal Pressman <gal@nvidia.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Aya Levin <ayal@nvidia.com>, Saeed Mahameed <saeedm@nvidia.com>,
	Jakub Kicinski <kuba@kernel.org>
Subject: Re: [PATCH net 1/2] mlx5: fix possible ptp queue fifo overflow
Date: Wed, 25 Jan 2023 12:33:46 -0800	[thread overview]
Message-ID: <Y9GSKrk95A4/Xo68@x130> (raw)
In-Reply-To: <45d08ca1-e156-c482-777d-df2bc48dffed@meta.com>

On 25 Jan 14:42, Vadim Fedorenko wrote:
>On 24/01/2023 14:39, Gal Pressman wrote:
>> Anyway, I'd like to zoom out for a second, the whole fifo was designed
>> under the assumption that completions are in-order (this is a guarantee
>> for all SQs, not just ptp ones!), this fix seems more of a bandage that
>> potentially hides a more severe issue.
>>
>>>
>>> It really shows that CQE are coming OOO sometimes.
>>
>> Can we reproduce it somehow?
>> Can you please try to update your firmware version? I'm quite confident
>> that this issue is fixed already.
>>

Hi Vadim, 

As Gal pointed out above,
we shouldn't be seeing OOO on TX data path, otherwise, what's the point
of the fifo ? Also you can't have a proper reseliency since it seems when
this OOO happen the skb_cc, which is derived from the we_counter seems to
fall out of range which makes me think it can be a completely random
value, so we can't really be protected from all OOO scenarios.

This is clearly a FW bug and we will get to the bottom of
this internally, Can you please create a bug request ?

For the SKB leak, I will take the 2nd patch as is and improve it as
necessary if that's ok with you.

Thanks,
Saeed.



  reply	other threads:[~2023-01-25 20:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-22 16:16 [PATCH net 0/2] mlx5: bugfixes for ptp fifo queue Vadim Fedorenko
2023-01-22 16:16 ` [PATCH net 1/2] mlx5: fix possible ptp queue fifo overflow Vadim Fedorenko
2023-01-23  7:20   ` Leon Romanovsky
2023-01-23 14:19     ` Vadim Fedorenko
2023-01-23 12:32   ` Gal Pressman
2023-01-23 23:49     ` Vadim Fedorenko
2023-01-23 17:24   ` Vadim Fedorenko
2023-01-24 14:39     ` Gal Pressman
2023-01-24 15:09       ` Vadim Fedorenko
2023-01-25 14:42       ` Vadim Fedorenko
2023-01-25 20:33         ` Saeed Mahameed [this message]
2023-01-25 21:24           ` Vadim Fedorenko
2023-01-22 16:16 ` [PATCH net 2/2] mlx5: fix skb leak while fifo resync Vadim Fedorenko
2023-01-23 12:38   ` Gal Pressman
2023-01-23 16:52     ` Vadim Fedorenko
2023-01-24  2:03     ` Jakub Kicinski

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=Y9GSKrk95A4/Xo68@x130 \
    --to=saeed@kernel.org \
    --cc=ayal@nvidia.com \
    --cc=gal@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=saeedm@nvidia.com \
    --cc=vadfed@meta.com \
    /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.