Date: Tue, 2 Feb 2010 14:43:28 -0800 From: Jack Vogel <jfvogel@gmail.com> To: pyunyh@gmail.com Cc: Nick Rogers <ncrogers@gmail.com>, Max Laier <max@love2party.net>, stable@freebsd.org, freebsd-stable@freebsd.org, jfv@freebsd.org Subject: Re: em(4) + ALTQ broken Message-ID: <2a41acea1002021443t1c298528i2df3cf40269c733@mail.gmail.com> In-Reply-To: <20100202223818.GD5901@michelle.cdnetworks.com> References: <147432021001310037n1b67f01bx4b4e8781321cea8@mail.gmail.com> <20100202173746.GA5901@michelle.cdnetworks.com> <2a41acea1002020948l6f3d1a08v9f4ccefd1241f566@mail.gmail.com> <201002022137.52064.max@love2party.net> <2a41acea1002021339i3801fc4bw736fa01188f60290@mail.gmail.com> <2a41acea1002021341s62633188g4560960157f5cd1@mail.gmail.com> <20100202223818.GD5901@michelle.cdnetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
It should never get to the drbr code, look at net/if_var.h, in the inline definition of drbr_dequeue() there is an #ifdef ALTQ that will effectively vector if to use the old IFQ_DRV_DEQUEUE() method. I guess I can test the build on a system here, stick some syntax error in and see if it hits. Right now the inserted code looks solid enough to me, so somehow I think its not being defined. Jack On Tue, Feb 2, 2010 at 2:38 PM, Pyun YongHyeon <pyunyh@gmail.com> wrote: > On Tue, Feb 02, 2010 at 01:41:01PM -0800, Jack Vogel wrote: > > LOL, and I can answer my own question, I just looked and the ONLY > > 1Gig drivers using multiqueue are mine, so I guess not eh? :) > > > > I was wrong. ALTQ is defined in opt_global.h so drbr_ interface > should already see ALTQ. I have to look into drbr_ code. > > > J. > > > > On Tue, Feb 2, 2010 at 1:39 PM, Jack Vogel <jfvogel@gmail.com> wrote: > > > > > Thanks Max, yes, i've done some digging myself and now see how things > > > work, the rubber meets the road in the defines in if_var.h. > > > > > > And what it does is effectively short circuit Kip Macy's multiqueue > code > > > in favor of the old method. > > > > > > Right now I can see two possibilities, either the defines are not set > in > > > the build, OR there is something wrong in the logic of the short > circuit > > > approach in Kip's code. > > > > > > A question might be if ANY driver that is usinig TX Multiqueue has been > > > successfully used with ALTQ? > > > > > > Jack > > > > > > > > > > > > On Tue, Feb 2, 2010 at 12:37 PM, Max Laier <max@love2party.net> wrote: > > > > > >> On Tuesday 02 February 2010 18:48:02 Jack Vogel wrote: > > >> > 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. > > >> > > >> The whole story is in > > >> > > >> man 9 altq > > >> > > >> long story short, as long as you consistently use the IFQ_* macros to > > >> manage > > >> the interface queue, things should just work. if_var.h used to > > >> conditionally > > >> define these macros to avoid ALTQ overhead when the kernel is built > > >> without > > >> ALTQ. This has changed a long time ago and should not make any > difference > > >> anymore. > > >> > > >> I can't figure out who the OP is, but could you make sure that the > > >> includes > > >> that are used to built the kernel are up to date? You are building > with > > >> the > > >> buildkernel target and not "the old way", right? Also, if you build > just > > >> the > > >> module, the build might pick up the includes from /usr/include instead > of > > >> src/sys ... > > >> > > >> > 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. > > >> > > > >> > _______________________________________________ > > >> > freebsd-stable@freebsd.org mailing list > > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > >> > To unsubscribe, send any mail to " > > >> freebsd-stable-unsubscribe@freebsd.org" > > >> > > > >> > > > >> > !DSPAM:4b686584144321871135632! > > >> > > > >> > > > > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2a41acea1002021443t1c298528i2df3cf40269c733>