Date: Tue, 2 Feb 2010 09:48:02 -0800 From: Jack Vogel <jfvogel@gmail.com> To: pyunyh@gmail.com Cc: Nick Rogers <ncrogers@gmail.com>, jfv@freebsd.org, stable@freebsd.org Subject: Re: em(4) + ALTQ broken Message-ID: <2a41acea1002020948l6f3d1a08v9f4ccefd1241f566@mail.gmail.com> In-Reply-To: <20100202173746.GA5901@michelle.cdnetworks.com> References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> <20100131224033.GA1107@michelle.cdnetworks.com> <147432021002020930y3591c278h6b07a235d3184752@mail.gmail.com> <20100202173746.GA5901@michelle.cdnetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
So apparently this thing needs no special knowledge in the driver, yet something in the new code breaks it, can someone explain tersely how the altq app actually "pokes" or "hooks up" to the driver? I am not clear about that and I suspect if I was this would all be clearer. Jack On Tue, Feb 2, 2010 at 9:37 AM, Pyun YongHyeon <pyunyh@gmail.com> wrote: > On Tue, Feb 02, 2010 at 09:30:52AM -0800, Nick Rogers wrote: > > > I guess the problem comes from multi-queue support. The drbr > > > interface is implemented with inline function so em(4)/igb(4) may > > > have to define ALTQ to the header. I have not tested the patch(no > > > time at this moment) but would you give it try? > > > > > > I tried the patch and it did not work. > > You rebuilt kernel, right? Rebuilding kernel module has no effect. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2a41acea1002020948l6f3d1a08v9f4ccefd1241f566>