netdev - Re: [PATCH net-next 6/6] docs: net: Add description of SyncE interfaces

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: <20211105143013.2cded2f3@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Fri, 5 Nov 2021 14:30:13 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     "Machnikowski, Maciej" <maciej.machnikowski@...el.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
        "richardcochran@...il.com" <richardcochran@...il.com>,
        "abyagowi@...com" <abyagowi@...com>,
        "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        "idosch@...sch.org" <idosch@...sch.org>,
        "mkubecek@...e.cz" <mkubecek@...e.cz>,
        "saeed@...nel.org" <saeed@...nel.org>,
        "michael.chan@...adcom.com" <michael.chan@...adcom.com>
Subject: Re: [PATCH net-next 6/6] docs: net: Add description of SyncE
 interfaces

On Fri, 5 Nov 2021 11:51:48 +0000 Machnikowski, Maciej wrote:
> > I'm still struggling to understand your reasoning around not making
> > EEC its own object. "We can do this later" seems like trading
> > relatively little effort now for extra work for driver and application
> > developers for ever.  
> 
> That's not the case. We need EEC and the other subsystem we wanted
> to make is the DPLL subsystem. While EEC can be a DPLL - it doesn't have
> to, and it's also the other way round - the DPLL can have numerous different
> usages.

We wanted to create a DPLL object to the extent that as a SW guy 
I don't understand the difference between that and an EEC. Whatever
category of *PLL etc. objects EEC is, that's what we want to model.

> When we add the DPLL subsystem support the future work will be as simple 
> as routing the EEC state read function to the DPLL subsystem. But if someone
> decides to use a different HW implementation he will still be able to
> implement his own version of API to handle it without a bigger DPLL block

All we want is something that's not a port to hang whatever attributes
exist in RTM_GETEECSTATE.