linux-kernel - Re: [PATCH v2 08/11] net: phylink: Adjust advertisement based on rate adaptation

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAA93jw7w1MY-4MWAQhSQG2BLrCjYApUPeFRB8fpuRtU-ZWYFEg@mail.gmail.com>
Date:   Thu, 21 Jul 2022 12:02:55 -0700
From:   Dave Taht <dave.taht@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     "Russell King (Oracle)" <linux@...linux.org.uk>,
        Sean Anderson <sean.anderson@...o.com>, netdev@...r.kernel.org,
        Heiner Kallweit <hkallweit1@...il.com>,
        Alexandru Marginean <alexandru.marginean@....com>,
        Paolo Abeni <pabeni@...hat.com>,
        "David S . Miller" <davem@...emloft.net>,
        linux-kernel@...r.kernel.org, Vladimir Oltean <olteanv@...il.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH v2 08/11] net: phylink: Adjust advertisement based on rate adaptation

On Thu, Jul 21, 2022 at 11:42 AM Andrew Lunn <andrew@...n.ch> wrote:
>
> > I guess it would depend on the structure of the PHY - whether the PHY
> > is structured similar to a two port switch internally, having a MAC
> > facing the host and another MAC facing the media side. (I believe this
> > is exactly how the MACSEC versions of the 88x3310 are structured.)
> >
> > If you don't have that kind of structure, then I would guess that doing
> > duplex adaption could be problematical.
>
> If you don't have that sort of structure, i think rate adaptation
> would have problems in general. Pause is not very fine grained. You
> need to somehow buffer packets because what comes from the MAC is
> likely to be bursty. And when that buffer overflows, you want to be
> selective about what you throw away. You want ARP, OSPF and other
> signalling packets to have priority, and user data gets
> tossed. Otherwise your network collapses.

Most of our protocols (like arp) are tolerant of some loss and taking
extraordinary measures to preserve "signalling" packets shouldn't be
necessary.

That said, how much buffering can exist here? How much latency between
emission, receipt, and response to a pause will there be?

>
>         Andrew



-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC