Date: Tue, 30 Oct 2007 21:06:39 -0600 From: Scott Long <scottl@samsco.org> To: Jack Vogel <jfvogel@gmail.com> Cc: "gnn@freebsd.org" <gnn@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD Stable List <freebsd-stable@freebsd.org>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: RFC: Evolution of the em driver Message-ID: <4727F13F.1030607@samsco.org> In-Reply-To: <2a41acea0710301001k60442b26uae186209ac484780@mail.gmail.com> References: <2a41acea0710291045m6f1d2acw78c26a455ea3894d@mail.gmail.com> <m2myu0q1f0.wl%gnn@neville-neil.com> <2a41acea0710301001k60442b26uae186209ac484780@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jack Vogel wrote: > On 10/30/07, gnn@freebsd.org <gnn@freebsd.org> wrote: >> At Mon, 29 Oct 2007 10:45:17 -0700, >> Jack Vogel wrote: >>> I have an important decision to make and I thought rather than just make >>> it and spring it on you I'd present the issues and see what opinions were. >>> >>> Our newer hardware uses new features that, more and more, require >>> parallel code paths in the driver. For instance, the 82575 (Zoar) uses >>> what are called 'advanced descriptors', this means different TX path. >>> The 7.0 em driver has this support in it, it just uses a function pointer >>> to handle it. >>> >>> When I add in multiqueue/RSS support it will add even more code >>> that functions this way. >>> >>> What the Linux team did was to split the newer code into a standalone >>> driver, they call it 'igb'. I had originally resisted doing this, but with >>> the development I have been working on the past month I am starting >>> to wonder if it might not be best to follow them. >>> >>> I see 3 possibilities and I'd like feedback, which would you prefer if >>> you have a preference and why. >>> >>> First, keep the driver as is and just live with multiple code paths >>> and features, possibly #ifdef'ed as they appear. >>> >>> Second, split the driver as Linux has into em and igb. The added >>> question then is how to split it, Linux made the line the use of >>> advanced descriptors, so Zoar and after, but I could also see a >>> case for having everything PCI-E/MSI capable being in the new >>> driver. >>> >>> Third, sort of a half-way approach, split up code but not the >>> driver, in other words offer different source files that can be >>> compiled into the driver, so you could have the one big jumbo >>> driver with all in there, or one that will only work with a subset >>> of adapters. This one would probably be the most work, because >>> its a new approach. >> As you're the main maintainer it's your choice. Whatever is easiest >> for you and gives us the most readable code. > > Thanks, I know its my choice, I was just looking for opinions about > the options I had to chose from :) > > I think I've had enough feedback to decide, I think the seperate > driver is the direction. I need to give some thought to where to > make the split. > > Thanks for everyone's feedback. > > Jack There are too many examples to name in every OS of drivers that have tried in vain to support diverging hardware evolutionary paths. if_dc and if_bge are great (or horrible, depending on your perspective) examples of this in FreeBSD. My vote is to nip the madness in the bud on if_em and have two (or more drivers) that support their hardware families well instead of one driver that supports multiple families marginally. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4727F13F.1030607>