Client Networking Issues / NIC Lab

[Kevin Bowling]

On Fri, Apr 23, 2021 at 6:19 AM Rick Macklem <rmacklem at uoguelph.ca> wrote:
>
> Kyle Evans wrote:
> >On Fri, Apr 23, 2021 at 12:22 AM Kevin Bowling <kevin.bowling at kev009.com> wrote:
> >>
> >> Greetings,
> >>
> >> [... snip ...]
> >>
> >> Tehuti Networks seems to have gone out of business.  Probably not
> >> worth worrying about.
> >>
> >
> >That's unfortunate. I had a box of their 10G NICs and I got them to
> >put a driver up for review[0][1], but they weren't very responsive and
> >the existing codebase was in pretty rough shape.
> >
> >Beyond that, your #3 seems to be the most appealing. #2 could probably
> >work in the mid-to-long term, but we'd likely be better off
> >bootstrapping interest with solid community-supported drivers then
> >reaching out to vendors once we can demonstrate that plan field of
> >dreams can work and drive some substantial amount of business.
>
> I'll admit to knowing nothing about it, but is using the linuxKPI
> to port Linux drivers into FreeBSD feasible?

Hi Rick,

I did consider this but do not think it makes sense for PCI Ethernet
NIC drivers.  I will explain my judgement for consideration.  In
complex systems such as an Ethernet driver, there are intrinsic and
extrinsic complexity.  The intrinsic properties of an Ethernet driver
are small enough that one person can understand them.  So we spend a
lot of time fighting against extrinsic problems that I outlined in my
email. Put in simpler terms, an iflib driver can be written by one
person and there are a number of people that are good at this in the
community.  The intrinsic complexity of the LKPI on top of an Ethernet
driver, as well as some license and social problems people have with
LKPI lead it to be a worse fit.

If you apply this to drm+i915 etc it is illuminating why the Linux KPI
is the right approach.  The intrinsic properties of the graphics stack
are beyond time and practicality for most in the community, the
graphics drivers have become labyrinths that most kernel devs don't
have internal knowledge of, rival the size of the rest of the kernel,
and keeping up is easier if internal code changes can be kept to a
minimum.

> Obviously, given the size of the Linux community, it seems
> more likely that it will have a driver that handles many chip
> variants, plus updates for newer chips, I think.

I would agree that Linux has a much better Realtek driver.  I am
familiar with the Linux e1000 series for instance, and although they
tend to have most the workarounds the quality is a lot lower than most
users realize.

> I do agree that having drivers that at least work for the
> basics (maybe no Netmap, TSO, or similar) for the
> commodity chips would make it easier for new adopters
> of FreeBSD. (I avoid the problem by finding old, used
> hardware. The variants of Intel PRO1000 and re chips I
> have work fine with the drivers in FreeBSD13/14.;-)

Having good inbox network drivers is a way for FreeBSD to
differentiate itself.  I like nice drivers like cxgbe(4), it is a
great piece of engineering and to me even artful.  Consider some cxgbe
so you can test high speeds :)

> Oh, and if TSO support is questionable, I think it would be
> better to leave it disabled and at least generate a warning
> when someone enables it, if it can be enabled at all.

I would like to preserve and correct TSO and other offloads as much as
possible.  There are consequences to half assing it such as burning
more electricity than necessary and causing unnecessary HW
upgrade/replacement.  Of course, where we can't deliver, we should
limit the feature set to known good ones.  Striking this balance will
require more feedback from the community, with faster turnaround time
on PRs.

> Good luck with it, rick
>
> Thanks,
>
> Kyle Evans
>
> [0] https://reviews.freebsd.org/D18856
> [1] https://reviews.freebsd.org/D19433
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>