netdev - Re: [RFC PATCH net-next 0/7] 802.1Q Frame Preemption and 802.3 MAC Merge support via ethtool

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

Message-ID: <20220817115008.t56j2vkd6ludcuu6@skbuf>
Date:   Wed, 17 Aug 2022 11:50:09 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Michal Kubecek <mkubecek@...e.cz>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Vinicius Costa Gomes <vinicius.gomes@...el.com>,
        Xiaoliang Yang <xiaoliang.yang_1@....com>,
        Kurt Kanzenbach <kurt@...utronix.de>,
        Rui Sousa <rui.sousa@....com>,
        Ferenc Fejes <ferenc.fejes@...csson.com>
Subject: Re: [RFC PATCH net-next 0/7] 802.1Q Frame Preemption and 802.3 MAC
 Merge support via ethtool

On Tue, Aug 16, 2022 at 08:34:17PM -0700, Jakub Kicinski wrote:
> On Wed, 17 Aug 2022 01:29:13 +0300 Vladimir Oltean wrote:
> >   What also exists but is not exported here are PAUSE stats for the
> >   pMAC. Since those are also protocol-specific stats, I'm not sure how
> >   to mix the 2 (MAC Merge layer + PAUSE). Maybe just extend
> >   ETHTOOL_A_PAUSE_STAT_TX_FRAMES and ETHTOOL_A_PAUSE_STAT_RX_FRAMES with
> >   the pMAC variants?
> 
> I have a couple of general questions. The mm and fp are related but fp
> can be implemented without mm or they must always come together? (I'd
> still split patch 2 for ease of review, tho.)

FP cannot be implemented without MM and MM makes limited (but some)
sense without FP. Since FP just decides which packets you TX via the
pMAC and which via the eMAC, you can configure just the MM layer such
that you interoperate with a FP-capable switch, but you don't actually
generate any preemptable traffic yourself.

In fact, the reasons why I decided to split these are:
- because they are part of different specs, which call for different
  managed objects
- because in an SoC where IPs are mixed and matched from different
  vendors, it makes perfect sense to me that the FP portion (more
  related to the queue/classification system) is provided by one vendor,
  and the MM portion is provided by another. In the future, we may find
  enough commonalities to justify introducing the concept of a dedicated
  MAC driver, independent/reusable between Ethernet controller ("net_device")
  drivers. We have this today already with the PCS layer in phylink.
  So if there is a physical split between the layers, I think keeping a
  split in terms of callbacks makes some sense too.

> When we have separate set of stats for pMAC the normal stats are sum of
> all traffic, right? So normal - pMAC == eMAC, everything that's not
> preemptible is express?

Actually not quite, or at least not for the LS1028A ENETC and Felix switch.
The normal counters report just what the eMAC sees, and the pMAC counters
just what the pMAC sees. After all, only the eMAC was enabled up until now.
Nobody does the addition currently.

> Did you consider adding an attribute for switching between MAC and pMAC
> for stats rather than duplicating things?

No. Could you expand on that idea a little? Add a netlink attribute
where, and this helps reduce duplication where, and how?