netdev - Re: [PATCH] Revert "macb: support the two tx descriptors on at91rm9200"

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAFr9PXmNgWqHeZe-He0vhdGcRZtPwQa3Jrd-1vz5VBB9RixgLA@mail.gmail.com>
Date:   Wed, 7 Apr 2021 20:54:02 +0900
From:   Daniel Palmer <daniel@...f.com>
To:     Willy Tarreau <w@....eu>
Cc:     Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        David Miller <davem@...emloft.net>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Claudiu Beznea <claudiu.beznea@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>
Subject: Re: [PATCH] Revert "macb: support the two tx descriptors on at91rm9200"

Hi Willy

On Wed, 7 Apr 2021 at 17:42, Willy Tarreau <w@....eu> wrote:
> > There are two new status bits TBNQ and FBNQ at bits 7 and 8. I have no
> > idea what they mean.
>
> Maybe they're related to tx queue empty / tx queue full. Just guessing.
> Since all these bits tend not to be reset until written to, I got confused
> a few times trying to understand what they indicated.

In the vendor driver they have some weird logic that counts idle, bnq,
and these 6 new bits,
and if the count of set bits is bigger than 5 it's apparently OK to
setup another frame to send.
I guess it's some really optimized form of checking for the right
flags but it's over my head. :D

You have to check it's OK to send right before setting the frame
address/length otherwise you will get an overflow eventually.
So I think some of these bits are related to the state machine that is
handling popping frames out of the FIFO and the bits might change
between getting a TX complete interrupt and trying to queue another
frame. i.e. you can have a situation where there seems to be a free
slot in the irq handler but it's not actually safe to queue it when
xmit is called, and if you do an overflow happens and the TX locks up.

> > Anyhow. I'm working on a version of your patch that should work with
> > both the at91rm9200 and the MSC313E.
>
> Cool! Thanks for letting me know. If you need me to run some test, let
> me know (just don't expect too short latency these days but I definitely
> will test).

I got this working really well last night. 10+ hours with the iperf3
bidir test and it's still going. Before TX locked up within a few
seconds.
Once I've cleaned it up a bit more I'll push it to my mstar tree. I
don't think it can be mainlined yet as it's not usable without a bunch
of other bits.

Cheers,

Daniel