netdev - Re: [PATCH net] bnxt_en: replace reset with config timestamps

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <bf5936da-e04d-37e4-00b2-81e9c6fa4170@novek.ru>
Date:   Wed, 21 Sep 2022 23:34:10 +0100
From:   Vadim Fedorenko <vfedorenko@...ek.ru>
To:     Michael Chan <michael.chan@...adcom.com>
Cc:     Pavan Chebbi <pavan.chebbi@...adcom.com>,
        Netdev <netdev@...r.kernel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCH net] bnxt_en: replace reset with config timestamps

On 21.09.2022 22:33, Michael Chan wrote:
> On Tue, Sep 20, 2022 at 7:36 AM Michael Chan <michael.chan@...adcom.com> wrote:
>>
>> On Mon, Sep 19, 2022 at 11:39 AM Vadim Fedorenko <vfedorenko@...ek.ru> wrote:
>>>
>>> Any change to the hardware timestamps configuration triggers nic restart,
>>> which breaks transmition and reception of network packets for a while.
>>> But there is no need to fully restart the device because while configuring
>>> hardware timestamps. The code for changing configuration runs after all
>>> of the initialisation, when the NIC is actually up and running. This patch
>>> changes the code that ioctl will only update configuration registers and
>>> will not trigger carrier status change. Tested on BCM57504.
>>>
>>> Fixes: 11862689e8f1 ("bnxt_en: Configure ptp filters during bnxt open")
>>> Cc: Richard Cochran <richardcochran@...il.com>
>>> Signed-off-by: Vadim Fedorenko <vfedorenko@...ek.ru>
>>> ---
>>>   drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c | 6 ++----
>>>   1 file changed, 2 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c
>>> index 8e316367f6ce..36e9148468b5 100644
>>> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c
>>> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c
>>> @@ -505,10 +505,8 @@ static int bnxt_hwrm_ptp_cfg(struct bnxt *bp)
>>>          ptp->tstamp_filters = flags;
>>>
>>>          if (netif_running(bp->dev)) {
>>> -               rc = bnxt_close_nic(bp, false, false);
>>> -               if (!rc)
>>> -                       rc = bnxt_open_nic(bp, false, false);
>>> -               if (!rc && !ptp->tstamp_filters)
>>> +               bnxt_ptp_cfg_tstamp_filters(bp);
>>> +               if (!ptp->tstamp_filters)
>>
>> Closing and opening is the correct sequence, but this might work too.
>> Please give us a day to review this.  Thanks.
> 
> We have internally discussed this issue in great detail.  If the user
> is changing the ALL_RX setting (enabling it or disabling it), just
> calling bnxt_ptp_cfg_tstamp_filters() is not sufficient.  The reason
> is that there is no synchronization after we send the new setting to
> the FW.  We don't know when valid timestamps will start showing up in
> the RX completion ring after turning on ALL_RX.  That's why we need to
> close and open.  After open, all RX packets are guaranteed to have
> valid timestamps.
> 
> So what we can do is to detect any changes to ALL_RX setting.  If
> ALL_RX is not changing, we can just do what this patch is doing.  If
> ALL_RX is changing, we can do something less intrusive than
> close/open.  We can just shutdown RX and restart RX.  This way we
> don't have to toggle carrier and cause a bigger disruption.
> 
Thanks for the review. I got your point regarding timestamps for all RX packets,
but for now I care about the case when ALL_RX is not supported. I can send a v2
with the check for this condition while you are working on the improvements for
all cases. Will it be to review and commit such patch?

Thanks.