Re: RFC: Evolution of the em driver
- From: "Kip Macy" <kip.macy@xxxxxxxxx>
- Date: Mon, 29 Oct 2007 17:13:57 -0700
Jack, you should know by now that we're not Linux. All we care about
is that you not break the code that we rely on. I'm still slightly
embarrassed when I explain to people that I build if_em as a module
because em0 doesn't come up sometimes due to a race condition on
initialization, so I need to be able to re-load the driver. We're
happy that you're keeping support for Intel's hardware up to date on
FreeBSD.
-Kip
On 10/29/07, Jack Vogel <jfvogel@xxxxxxxxx> 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-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"
- References:
- RFC: Evolution of the em driver
- From: Jack Vogel
- RFC: Evolution of the em driver
- Prev by Date: Re: Realtek Gigabit Network Card 0xd6088086
- Next by Date: Re: Realtek Gigabit Network Card 0xd6088086
- Previous by thread: RFC: Evolution of the em driver
- Next by thread: Re: RFC: Evolution of the em driver
- Index(es):
Relevant Pages
|
|
