Message-ID: <20220817114642.4de48b52@kernel.org>
Date:   Wed, 17 Aug 2022 11:46:42 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Vladimir Oltean <vladimir.oltean@....com>
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 Wed, 17 Aug 2022 11:50:09 +0000 Vladimir Oltean wrote:
> On Tue, Aug 16, 2022 at 08:34:17PM -0700, Jakub Kicinski wrote:
> > 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.

Hah, interesting. I was under the impression that FP can be done
without MM, if frame is preempted it just gets scrambled (bad FCS 
gets injected or a special symbol) and dropped by the receiver.
I had it completely backwards, then.

> > 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.

I see. And the netdev stats are the total?

> > 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?

Add a attribute to ETHTOOL_MSG_STATS_GET, let's call it
ETHTOOL_A_STATS_EXPRESS, a flag.

Plumb thru to all the stats callback an extra argument 
(a structure for future extensibility) with a bool pMAC;

Add a capability field to ethtool_ops to announce that
driver will pay attention to the bool pMAC / has support.

We can then use the existing callbacks.

Am I making sense?

Powered by blists - more mailing lists