Just teseted, and at least in the kernel build I'm doing its definitely defining that code on, hit my syntax error rebuilding em.
Jack On Tue, Feb 2, 2010 at 2:43 PM, Jack Vogel <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> > >> 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. >> > >> > >> > >> > _______________________________________________ >> > >> > [email protected] mailing list >> > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > >> > To unsubscribe, send any mail to " >> > >> [email protected]" >> > >> > >> > >> > >> > >> > !DSPAM:4b686584144321871135632! >> > >> > >> > >> >> > > >> > > >> > > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
