Date: Tue, 30 Oct 2007 10:01:48 -0700 From: "Jack Vogel" <jfvogel@gmail.com> To: "gnn@freebsd.org" <gnn@freebsd.org> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD Stable List <freebsd-stable@freebsd.org> Subject: Re: RFC: Evolution of the em driver Message-ID: <2a41acea0710301001k60442b26uae186209ac484780@mail.gmail.com> In-Reply-To: <m2myu0q1f0.wl%gnn@neville-neil.com> References: <2a41acea0710291045m6f1d2acw78c26a455ea3894d@mail.gmail.com> <m2myu0q1f0.wl%gnn@neville-neil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2a41acea0710301001k60442b26uae186209ac484780>