RFC: Evolution of the em driver

Brian McGinty brian.mcginty at gmail.com
Mon Oct 29 22:51:12 PDT 2007


I prefer (2) - non-intrusive on em,  and the new one doesn't have to deal
with legacy or backward compatibility with em.

Any commonality with ixgbe?

Later

Brian.

On 10/29/07, Jack Vogel <jfvogel at gmail.com> 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.
>
> Cheers,
>
> Jack
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>


More information about the freebsd-stable mailing list