Date: Fri, 23 Apr 2021 15:12:06 -0700 From: Kevin Bowling <kevin.bowling@kev009.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: Client Networking Issues / NIC Lab Message-ID: <CAK7dMtDfvvKBYn8UnyFpoS3HY0LB6dHupD-40cVaO4HRkbw8GA@mail.gmail.com> In-Reply-To: <YQXPR0101MB0968C64183DEDEF76AD3EE77DD459@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> References: <CAK7dMtBy=wvi4=ES6yhO0t%2BVfXcjcTtSuMK1_Vt3t3eZPY53Yg@mail.gmail.com> <CACNAnaEah_4JT=NHWPUJu8CdrD83CJbmVvjNJse0WVmW4Wz6nw@mail.gmail.com> <YQXPR0101MB0968C64183DEDEF76AD3EE77DD459@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 23, 2021 at 6:19 AM Rick Macklem <rmacklem@uoguelph.ca> wrote: > > Kyle Evans wrote: > >On Fri, Apr 23, 2021 at 12:22 AM Kevin Bowling <kevin.bowling@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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAK7dMtDfvvKBYn8UnyFpoS3HY0LB6dHupD-40cVaO4HRkbw8GA>