netdev - Re: [PATCH RFC] net: sfp: support assigning status LEDs to SFP connectors

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: <20220511144802.htkzgisedkkcdwhd@skbuf>
Date:   Wed, 11 May 2022 14:48:04 +0000
From:   Ioana Ciornei <ioana.ciornei@....com>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
CC:     Andrew Lunn <andrew@...n.ch>, Josua Mayer <josua@...id-run.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [PATCH RFC] net: sfp: support assigning status LEDs to SFP
 connectors

On Wed, May 11, 2022 at 11:26:12AM +0100, Russell King (Oracle) wrote:
> On Tue, May 10, 2022 at 02:13:42PM +0200, Andrew Lunn wrote:
> > > > As far as i'm aware, the in kernel code always has a netdev for each
> > > > MAC. Are you talking about the vendor stack?
> > > The coprocessor can be configured both at boot-time and runtime.
> > > During runtime there is a vendor tool "restool" which can create and destroy
> > > network interfaces, which the dpaa2 driver knows to discover and bind to.
> > 
> > There should not be any need to use a vendor tool for mainline. In
> > fact, that is strongly discouraged, since it leads to fragmentation,
> > each device doing its own thing, the user needing to read each vendors
> > user manual, rather than it just being a standard Unix box with
> > interfaces.
> 
> You're missing the bigger picture.
> 
> There are two ways to setup the networking on LX2160A - one is via
> DT-like files that are processed by the network firmware, which tells
> it what you want to do with each individual network connection.
> 
> Then there is a userspace tool that talks to the LX2160A network
> firmware and requests it to configure the network layer - e.g. create
> a network interface to connect to a network connection, or whatever.

Yes, that is correct.
Beside that, the userspace tool is not mandatory by any means. You can
do the necessary setup at boot time.

> 
> I believe that when using DPDK, one does not want the network
> connections to be associated with Linux network interfaces - but
> don't quote me on that.

Hmm, not exactly true.

Yes, when using DPDK there won't be a typical network interface exported
by the dpaa2-eth driver present upstream. But there is a downstream only
driver will which take care of the phy, pcs, MAC part with phylink's
help so that DPDK can only concentrate on the fast path.

We did this so that we can leverage the phylink integration with DPDK
also, but we are not pushing it to upstream since it's not really clean
to have a netdev just for configuration purposes.

Ioana