Re: RFC: Evolution of the em driver

Jack Vogel wrote:
> On 10/30/07, gnn_at_freebsd.org <gnn_at_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