Message-ID: <CAKgT0UcO-=dg2g0uFSMt2UnyzF7y2W8RVFDp15RZhy=Vb4g61Q@mail.gmail.com>
Date: Thu, 11 Apr 2024 09:00:17 -0700
From: Alexander Duyck <alexander.duyck@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Jakub Kicinski <kuba@...nel.org>, pabeni@...hat.com, 
	John Fastabend <john.fastabend@...il.com>, Alexander Lobakin <aleksander.lobakin@...el.com>, 
	Florian Fainelli <f.fainelli@...il.com>, Daniel Borkmann <daniel@...earbox.net>, 
	Edward Cree <ecree.xilinx@...il.com>, netdev@...r.kernel.org, bhelgaas@...gle.com, 
	linux-pci@...r.kernel.org, Alexander Duyck <alexanderduyck@...com>, 
	Willem de Bruijn <willemdebruijn.kernel@...il.com>
Subject: Re: [net-next PATCH 00/15] eth: fbnic: Add network driver for Meta
 Platforms Host Network Interface

On Wed, Apr 10, 2024 at 3:37 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> > Well I was referring more to the data path level more than the phy
> > configuration. I suspect different people have different levels of
> > expectations on what minimal firmware is. With this hardware we at
> > least don't need to use firmware commands to enable or disable queues,
> > get the device stats, or update a MAC address.
> >
> > When it comes to multi-host NICs I am not sure there are going to be
> > any solutions that don't have some level of firmware due to the fact
> > that the cable is physically shared with multiple slots.
>
> This is something Russell King at least considered. I don't really
> know enough to know why its impossible for Linux to deal with multiple
> slots.

It mostly has to do with the arbitration between them. It is a matter
of having to pass a TON of info to the individual slice and then the
problem is it would have to do things correctly and not manage to take
out it's neighbor or the BMC.

> > I am assuming we still want to do the PCS driver. So I will still see
> > what I can do to get that setup.
>
> You should look at the API offered by drivers in drivers/net/pcs. It
> is designed to be used with drivers which actually drive the hardware,
> and use phylink. Who is responsible for configuring and looking at the
> results of auto negotiation? Who is responsible for putting the PCS
> into the correct mode depending on the SFP modules capabilities?
> Because you seemed to of split the PCS into two, and hidden some of it
> away, i don't know if it makes sense to try to shoehorn what is left
> into a Linux driver.

We have control of the auto negotiation as that is north of the PMA
and is configured per host. We should support clause 73 autoneg.
Although we haven't done much with it as most of our use cases are
just fixed speed setups to the switch over either 25G-CR1, 50G-CR2,
50G-CR1, or 100G-CR2. So odds are we aren't going to be doing anything
too terribly exciting.

As far as the QSFP setup the FW is responsible for any communication
with it. I suspect that the expectation is that we aren't going to
need much in the way of config since we are just using direct attach
cables. So we are the only one driving the PCS assuming we aren't
talking about power-on init where the FW is setting up for the BMC to
have access.

We will have to see. The PCS drivers in that directory mostly make
sense to me and don't look like too much of a departure from my
current code. It will just be a matter of splitting up the fbnic_mac.c
file and adding the PCS logic as a separate block, or at least I hope
that is all that is mostly involved. Probably take me a week or two to
get it coded up and push out the v2.

Powered by blists - more mailing lists