Client Networking Issues / NIC Lab

[George Neville-Neil]

On 23 Apr 2021, at 18:12, Kevin Bowling wrote:

> 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"
>>

On the NIC Lab question, anyone on the project (and some off) can use 
the lab we built for high performance networking at Sentex.  This lab 
has plenty of machines and excellent remote hands:

https://wiki.freebsd.org/TestClusterOnePointers

https://wiki.freebsd.org/TestClusterOneReservations

Folks are welcome to contact me off list for access.

Best,
George