Re: [PATCH 00/23] Subject: [PATCH net-next 00/23] net/hpe: add HPE Slingshot NIC drivers

[Andrew Lunn]

On Sun, Nov 01, 2026 at 07:45:24PM -0800, Doug Ledford wrote:
> On 11/1/26 5:35 PM, Andrew Lunn wrote:
> >> I'll see how fast I can get that done.  But "the bare minimum" is going
> >> to be more than you are accustomed to.  This hardware does not receive
> >> Ethernet packets using MAC address like normal Ethernet hardware.  It
> >> uses a special portal table entry that filters in the Ethernet packets.
> >> It has the ability to have different filters that receive different
> >> Ethernet packets and so sorts them before the driver ever sees them.
> > 
> > Can you add a single portal entry which matches everything? Or matches
> > a single MAC address? KISS.
> 
> That's a complex question, and one which I need to go talk to one of the
> hardware engineers about.  It also varies based upon your meaning of
> "everything".  If, by everything you means essentially promiscuous mode,
> then that's not a good idea.  On the fabric there is Ethernet traffic,
> but there is also Slingshot traffic.  They use totally different frame
> types.  If you truly go for "everything", you'll get Slingshot traffic
> along with Ethernet traffic and you'll be throwing away tons of garbage
> and generally wondering what's going on.

The point is you want a very simple driver which it is possible to
review.

This is one of those 0, 1, many cases. Just having one portal entry
means you don't need any allocation algorithm, you don't need recovery
when it overflows, you don't need to be able to replace it, reference
counting, etc. It gives you a starting point to expand later in a
followup patch set which adds all these things.

The network stack is happy to handle promiscuous mode, it does it all
the time when you use ethtool and put the interface into promisc mode.
It is clearly not as efficient as having the hardware doing filtering,
but it works.

> If by "everything" you just
> mean "all Ethernet traffic on a single portal entry", that's when I have
> to go talk to the hardware engineers.  They have different lists they
> use for Ethernet and I can't say for certain that the hardware will
> allow not using those lists.  For instance, one of the lists might be
> specifically for packets that have been fragmented and if you don't use
> that list for those packets it may not receive them at all.

Think about this from the other direction. How does promisc mode work?

> The card has a burned in MAC address.

That is one of the MAC addresses it needs to receive. But when you
come to implement .ndo_set_rx_mode you are given a list of unicast and
multicast MAC addresses you are supposed to receive. And if the
hardware cannot do a perfect match, you do a less perfect match and
let the stack deal with the rest.

> I did have the AI do a full analysis of what you requested.  A bare
> minimal driver.  It passed this back (just giving the summary, not the
> full report):
> 
> Estimated total for a C2-only, PF-only Ethernet series:
> 
> ss1 about 19–20k
> SL about 15–20k
> headers about 15–20k
> That gives roughly 50–60k lines, or about 65k if C1 support stays.

How does it define bare minimum.

If you have thrown out ethtool, you cannot change or report the link
speed. If you cannot change the link speed, and you have followed IEEE
802.3, your PCS will probably just come up when powered on, since the
standard gives the registers sensible defaults. So all your PCS driver
needs to do is poll for link. A typical PCS driver is around 2K lines
of code, and that actually does more.

    Andrew